Már alíg várjuk a frisstéseket, ugye? Azonnal fel is tesszük, mert milyen jó is az, ráadásul a Microsoft is azt javasolja, hogy tegyük fel, meg egyébként a premier support is visszadobja a problémát. Az elmúlt időszakban két olyan probléma is volt, ami érintette az SQL Servert használókat:
- RsFx driver probléma: erről itt lehet olvasni a részleteket.
- Windows 10 Creators update: ez egy új probléma :) egy még most kiadásban lévő frissítéssel. Röviden: ha nem LocalSystem nevében fut az SQL Server vagy nem tagja a helyi Administrators csoportnak a service account felhasználó, akkor a FileStream nem működik. Na vajon miért? :) RsFX :) A probléma részletesen itt olvasható.
Ennek margóján megosztanám azokat az irányelveket, amiket próbálok követni a frissítések során (már, ha hagyják :)):
Alapvetően 3 csoportba osztom a frissítéseket:
- Firmware/BIOS
- OS/Driver/.NET
- SQL Server
Firmware/BIOS
Alapvetően a gyártók által kiadott frissítések, amelyket időről-időre frissíteni kellene. Csak az érdekesség kedvéért: van olyan RAID vezérlő, aminek egy régebbi firmware verziója miatt néha "elfelejti" a konfigurációt. Ugyan ezen a vonalon pedig van olyan is, hogy ugyan ennek a gyártónak a lemezei nem kompatibilisek ezzel a vezérlővel. Innen szép nyerni... Gondolom világossá vált, hogy nem csak a frisstíés, de a tervezés során is fontos ezeket megnézni (nem muszály, de sok fejfájástól és önéletrajz frissítéstől kímélhetjük meg magunkat)
OS/Driver/.NET
Ahogy a firmware/BIOS-t is, úgy az operációs rendszert is frissíteni kell. Fontos, hogy ezen belül is a driverekre és a .NET Framewrok-re is oda kell figyelni. Az SQL Server bizonyos részei használják a .NET komponenseket, illetve ne feledkezzünk meg a hálózatról is, ami ugye egy hálókártyával van megoldva, amit egy driver miatt tudunk használni.
SQL Server
Az SQL Server esetében több különböző frisstés típusról beszélhetünk:
- RTM: ez ugyan nem frisstíés, ez az alap verzió a kiadás után
- CU: Cummulative update, ez az RTM vagy egy SP után egy közbenső release. A Microsoft álláspontja, hogy az SQL Server 2014+ verziókhoz kiadott CU-k már olyan teszteken esnek át, hogy nyugodtan fel lehet rakni ezeket (na persze :))
- Hotfix/QFE: ezek olyan, általában biztonsági javítások, amelyek telepítése egy-egy komolyabb, sűrgősen megoldandó problémát hivatottak javítani (pl: SSL)
- SP: Service Pack, egy adott verzió esetén ez egy major release, ami akár nagyon komoly változásokat is okozhat a termékben, mint pl. az SQL Server 2016 SP1, amelynél a teljes fejlesztői eszközkészlet az Express verziótól, az Enterprise verzióig elérhető. Igen, akár a particionálás vagy az in-memory is :)
Szóval nem is olyan egyszerű ez, mint amilyennek látszik. Akkor mégis, hogyan lehet ezt jól csinálni? A válasz: nehezen vagy sehogy. Miért? Leginkább az ok a költséghatékonyság (mindjárt látni fogjuk, miért is írom ezt).
Ahhoz, hogy megfelelő módon tudjuk frissíteni az SQL Servert kiszolgáló szervereinket és magát a szolgáltatást, optimálisan ezekre lenne szükség:
- teljesen identikus hardver környezet (firmware, BIOS): ugye mondanom sem kell, hogy költség oldalról ez nem éppen a kedvence egy cégnek se (egészen az első problémáig!)
- teljesen identikus konfiguráció: ez sem szokott erősség lenni :)
- teljesen egyező frissítési/patch szint: ez aztán már szinte az álom kategória
- dokumentált frissítési eljárás: őőő :) no comment :)
Természetesen nem azt mondom, hogy ez mindenhol problémás, de elég sok helyen lehet probléma a fentiek minimális teljesítése is.
Persze lehet jönni, hogy WSUS, cluster-aware update meg virtualizált környezetben csináljuk. Mindegyikre tudok jó és ellenpéldát is hozni. Maradjunk annyiban, hogy érdemes megnézni, hogy egy leállás miatt mekkora vesztesége lenne a cégnek (akár elmaradt haszon), illetve mekkora anyagi ráfodítással lehet megoldani ezt a problémát. Ezen tovább, már csak úgy érdemes gondolkodni, hogy át kell gondolni a HA/BCP/DRP folyamatokat is.
Tételezzük fel, hogy megvannak a szükséges eszközeim, akkor a következő folyamat mentén szoktam a frissítéseket elvégez(tet)ni (a teljesség igénye nélkül):
- firmware/BIOS: legalább negyedévente ellenőrizni kell a gyártó oldalát, majd ennek alapján a teszt rendszerre telepítve ellenőrizni minden működést. Célszerű feliratkozni a gyártók által küldött emailekre ebben a témában vagy RSS feed-re. Komoly figyelmet kell szentelni a kompatibilitásnak is!
- OS/.NET/Driver: ez nagyrészt a Windows Update által jön. Érdemes WSUS segítségével kontrollálni ezeket, illetve egy ellenőrzőlista alapján végiogpróbálni a komponenseket, lásd bevezetésben az RsFx driver miatti problémát, ami Windows update és SQL update miatt is okoz(ott) problémát.
- SQL Server: SP, CU, Hotfix, QFE telepítése is mindig a teszt rendszerre kell, hogy történjen először. Pontosan amiatt, mert megváltoztathat funkciókat, amik nem várt működést eredményezhetnek az éles környezetben. Általában 1-3 havonta van CU/QFE/Hotfix, így érdemes ilyen időbeli csúsztatással tesztelni és az éles rendszerre bevezetni ezeket. Már csak azért is fontos a teszt, mert ugye még emlékszik mindenki a nagy sikerű SQL Server 2014 SP1-re. Na ugye :)
Összességében nem is olyan triviális feladat, mint amilyennek ez tűnik. Nagyon fontos a tervezés, illetve ne féljünk kérdezni!