Mire figyeljünk az SQL Server frissítése során

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:

  1. RsFx driver probléma: erről itt lehet olvasni a részleteket.
  2. 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:

  1. Firmware/BIOS
  2. OS/Driver/.NET
  3. 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!

Add comment