Teszt és tapasztalatok: kipróbáltuk az SSD-k legújabb generációját

Nemrégiben felújításra került az otthoni gépem, a régi 8 magos AMD FX processzor helyére egy új Ryzen érkezett, AM4-es alaplappal és DDR4-es RAM-okkal. Gondoltam ha már lúd legyen kövér és a régi jól bevált SATA-s SSD-t is lecserélem egy M2-es foglalatúra, úgyis kevés volt a hely. A választás a Samsung 960 EVO-ra esett, 250GB-os méretben. A gyártó 3200MB/s olvasási és 1900MB/s írási sebességet ígért. A cikkből kiderül mi a valós teljesítmény és milyen egyéb buktatók jelentkeztek a használat során.

Samsung 960 Evo
Samsung 960 Evo

 

Az NVMe (más néven NVM Express) típusú SSD nem újkeletű dolog, a lényeg azon van, hogy a kis M2 foglalat segítségével egy csavarral rögzített, kinézetében a hagyományos RAM-okra hasonlító SSD-t a SATA adat csatorna helyett a PCIe buszra csatolja rá. Míg a SATA3 szabvány elméleti maximuma 600MB/s körül mozog, addig a PCIe 4.0 szabvány ennek a sokszorosát biztosítja. Persze nem csupán ennyi különbség van a két szabvány közt, aki kíváncsi a részletekre, nézzen szét itt: https://en.wikipedia.org/wiki/NVM_Express
Az alábbi táblázatban láthatjuk a PCIe foglalat különböző verziói által elérhető sávszélességeket, ezek közül a 4.0 szabvány a jelenlegi legújabb, az 5.0 2019-re várható a tervek szerint.

PCIe szabványok és átviteli sebességek
PCIe szabványok és átviteli sebességek

A nagyobb sávszélesség és a jelenlegi félvezető technológia tehát megadja a lehetőséget, hogy növelt sebességű tárolókat használjuk, a jelenleg is remek teljesítményt nyújtó SATA SSD-k helyett még gyorsabb M2 foglalatba illeszkedő NVMe modulokat. Persze a történet azért nem ennyire egyszerű, ahogyan a cikk végére látni fogjuk rengeteg buktatót kell kiküszöbölnie azoknak, akik valóban gyors tárolót akarnak és mellé a stabilitás sem utolsó szempont. Elsőként említeném meg, hogy aki NVMe-re adja a fejét az mindenképpen bizonyosodjon meg róla, hogy a legfrissebb BIOS (UEFI) fut az alaplapján. Ahogy említettem nem újkeletű technológiáról van szó, viszont kezdetben az alaplapok hiába tudták fogadni az ilyen csatolóval érkező tárolókat, bootolni már nem voltak képesek róla. Így a friss Windows telepítésekor azt tapasztalhatjuk, hogy az első újraindítást követően “no boot device” üzenet fogad minket. A BIOS-hoz visszatérve azzal sem árt tisztában lenni, hogy az M2 foglalat használatával a legtöbb alaplap esetében SATA portokat veszítünk el, ahogyan az én ASUS-om esetében is le kellett mondjak az 5-6. portról.

Ha a legfrissebb BIOS fent van, újabb szoftveres buktatók következnek. (Itt fontos megjegyeznem, ha kicsit is bizonytalanok vagyunk a BIOS frissítés terén ne féljünk segítséget kérni szakembertől.) Ennyire új hardverek esetében talán már mondanom sem kell, hogy mindenképp a Windows 10-et javaslom, ahogy a tapasztalat megmutatta abból sem érdemes a legrégebbi telepítőkkel kísérletezni. A 1607-es változat már gond nélkül kúszott fel az SSD-re, majd a telepítést követően azonnal frissítésre került a 1703-asra. A legfrissebb driverek felkerültek, elkezdhettem belakni a gépet. A gép nagyon fürge lett, az első pillanattól kezdve nem okozott csalódást, a 1703-as Windows frissítés is a letöltést követően percek alatt felkerült rá. Az első mérések szerint az SSD közel tudta azt a sebességet, amit a Samsung ígért. Aztán jött a feketeleves.

Második nap először egy nagyobb program telepítése (25-30GB) alatt iszonyatos laggolást vettem észre. Elsőre nem tudtam mitől van, de 2-3 órányi szenvedést (egér kurzor megáll, folyamatjelző percekig áll, továbbmegy, megint megáll…) követően némi guglizás után kiderült, hogy a probléma a Ryzen processzor körül keresendő, annak is az energiagazdálkodása okoz gondot a 1703-as Windows-nak. (A Ryzen ne feledjük a második negyedévben érkezett, míg a 1703-as Windows verzió a márciusra utal, tehát némiképp felkészületlen volt még a rendszer rá.) Sokan ezt az Insider programon belül letöltött 1709-es frissítés előzetesével orvosolták sikerrel, nekem nem volt kedvem kísérletezni, így az energiagazdálkodásban eszközöltem pár ajánlott módosítást, ami után sikeresen fel tudtam telepíteni a programot. Az egér kurzor rendszeres akadozása (régebbi gépekről ismert megszakítás vezérlési hiba) ugyanakkor megmaradt és még aznap este jött az újabb probléma. Amikor munkába lendültem volna a gép kb. óránként fagyott. Elsőre a mentés gombra kattintva kezdett homokozni, majd a megnyitott ablakok közt még lehetett váltani pár alkalommal, majd kb. fél perc múlva az egér kurzor is megfagyott. Ez már inkább tároló problémának tűnt. Végül kiderült, hogy jó a megérzésem, a 1703-as Windowsban már megjelent egy új energiagazdálkodási funkció kimondottam NVMe szabványra vonatkozóan, amit első körben registryből kellett bekapcsolni, majd egy fórum ajánlása alapján beállítottam az értékeket. A fagyás megszűnt.

NVMe energiagazdálkodás beállítása
A problémámat orvosló beállítások

A gép ezt követően már stabil maradt, megszűntek a laggolások és a fagyások is. Egyedül az egérkurzor véletlenszerűen visszatérő akadozás problémája nem szűnt meg, de tudtam, hogy a Ryzen processzor kezelése majd csak a 1709-es Windows verzióban lesz tökéletes, addig pedig ekkor már csak 1 hét volt, kivártam. A 1709-es frissítés aztán minden korábbi problémát orvosolt, így mostanra egy stabil és gyors gépen dolgozhatok.

A Samsung SSD esetében fontos még szót ejteni a hozzá adott Samsung Magician szoftverről. Egy nagyon hasznos kis alkalmazást kapunk hozzá, amivel könnyedén nyomon követhetjük a meghajtó állapotát, mérhetjük a sebességét, optimizálhatjuk a meghajtót (TRIM), és az over provisioning funkció segítségével növelhetjük a meghajtó teljesítményét és élettartamát.

Samsung Magician
Samsung Magician, a nagy varázsló

Elsőként essen szó a Magician féle teljesítmény mérésről. A metodika ismeretlen, mindenesetre 3200MB/s-tól a 2000-ig terjedő skálán ahány mérés annyiféle eredmény született nem kis szórással. Hozzá kell tenni a rendszer ez idő alatt az SSD-ről futott, ahogyan majd a későbbi AIDA tesztekben is így lesz, ez némiképpen árnyalja az eredményt. A 2000MB/s is szép eredmény mindenesetre, nem beszélve az elérési időkről, az IO eredményekről.

Samsung Magician teljesítmény teszt
Samsung Magician teljesítmény teszt, a legalacsonyabb kapott értékek

Az over provisioningról is érdemes néhány szót ejteni. Akik kicsit jártasabbak az SSD technikában azok tudják, hogy az SSD-k esetében szokás egy bizonyos területet fenntartani és nem használni. Ha van szabad terület az SSD némi trükközéssel spórolni tud az adatblokkok felülírásának számán, ami az élettartamának legnagyobb ellensége. Ennek a folyamata és mikéntje egy külön cikket is megérne, most maradjunk annyiban, ha az SSD-nek van olyan szabad, formázatlan területe, ami nincs használatban azzal tudja növelni az élettartamot. Ebben segít nekünk az over provisioning funkció, ami ezt automatikusan beállítja nekünk. Vannak olyan SSD-k is, amelyekben gyárilag ki van ez alakítva és nem kell vele törődjünk, általában a méretéből látszik melyik ilyen. Például a 240GB-os SSD-k rendre 256GB-osak fizikailag, itt 16GB van fenntartva gyárilag, amit a lemezkezelőben már nem is látunk. A Samsung Magician-ben ez megjelenik, vélhetően itt nincs gyárilag rejtett terület.

Végül következzenek az AIDA által mért eredmények szépen sorjában. A linear read test suite lényegében minden fontos paraméterre megadja nekünk a mérési eredményt. Érdemes viszont megnézni az average read access tesztet is, ami az átlagos elérési időket mutatja meg. Ez az az érték, ami igazán pörgőssé tesz egy SSD-t és ez az, amiben a hagyományos merevlemezekhez képest utcahossznyi, behozhatatlan előnye van. Míg egy jobb merevlemez elérési ideje átlag 8-10ms körül mozog, a véletlenszerű adatelérés esetén, amikor a fejnek be kell gyűjteni az adatokat ez még több, addig az NVMe típusú SSD 0.05ms értékkel hasít.

AIDA olvasás tesztek
AIDA olvasás tesztek
AIDA átlagos elérési idő teszt
AIDA átlagos elérési idő teszt

A gyakorlati tapasztalat azonban egy picit más képet fest. 2 hónapnyi használat után azt mondhatom, hogy az esetek nagy többségében, a mindennapi használatban a szupergyors NVMe SSD előnyei nem jönnek elő. A korábbi SATA OCZ-vel összehasonlítva, ami gyári előírás szerint 500MB/s körül tudott, a gyakorlatban picit kevesebbet, a kettő közti sebesség nem vehető észre. A “csak” 500MB/s és a picit nagyobb késleltetés mellett is mire az egérgombot felengedtem megnyílt a böngésző, vagy a kisebb program, Office alkalmazás, amit épp használtam. Egy Adobe Photoshop vagy Illustrator már picit többet tekert, most a legújabb verzió betöltési ideje 3 másodperc körül van. (Nyilván ebben némi szerepe azért a CPU-nak és a DDR4-es memóriának is van.) Amikor a program betöltött a működése alatt nem venni észre különbséget, ha menteni kell jellemzően azért nem akkora fájlokat, ami a régi SATA SSD-n percekbe telt volna. Nyilván 0,6 másodperc és 0,2 között nem érzékel az ember akkora különbséget, mert íráskor kb. ennyi a különbség az NVMe javára. Olvasáskor picit nagyobb, de itt megintcsak nem jön elő a különbség, csak ritka esetekben érzékelhető. Kicsit az embernek az az érzése, mintha anno a HDD-ről SSD-re váltáskor egy kis köbcentis régi Suzukiból egy jóval nagyobb lóerejű, villámgyors német prémium autóba ülne át, majd azt cserélné egy 1000 lóerő környéki sportkocsira. Ritka az az eset, amikor igazán elő tud jönni a plusz erő és még hasznos is tud lenni. Picit sántít azért a példa, mert vannak sokan olyanok, CAD-es programokkal dolgozó mérnökök, videóvágással, esetleg 3D-vel foglalkozó emberek vagy hardcore játékosok, akiknek napi szinten segítséget nyújthat, de a mindennapok emberének nem fog többet nyújtani egy ilyen SSD. Az ára miatt ugyanakkor egyre inkább elérhetővé válik a technika, a kipróbált Samsung 250GB-os SSD például 30 ezer nettó körüli áron már elérhető, ami alig pár ezer forinttal drágább, mint hasonló kapacitású, márkás SATA csatlakozóval ellátott társai. Ha valaki olyan munkát végez mindenképpen megéri neki befektetni egy ilyenre, otthoni felhasználásra vagy irodába ugyanolyan élményt nyújt továbbra is a hagyományos SSD. Cserében viszont kevesebb szoftveres problémával kell megküzdeni.

A tesztben szereplő SSD-t az alábbi hardverekkel teszteltük.
Alaplap: ASUS Prime B350-Plus (0902-es BIOS)
Processzor: AMD Ryzen 5 1500X
Memória: Kingston 2133MHz DDR4

Exchange Server migrálás linuxos levelezőről

Az alábbi sikertörténet valójában két jól sikerült munkát foglal össze. Korábban több alkalommal vittünk már véghez olyan jellegű migrálást, amikor nem volt a cégnek korábban saját levelező rendszere, csak (jobb esetben) Outlook-ba beállított levelezés, (rosszabb esetben) Thunderbird vagy valami egyéb levelezőprogram, esetenként webmail. Ilyenkor általában a meglévő levelező programba a régi fiók mellé csatoltuk mindig az új fiókot és IMAP segítségével kézzel mozgattuk át a korábbi leveleket. Jobb esetben Outlook PST-ből tudtunk közvetlenül importálni egy frissen felépített Exchange rendszerbe.

Exchange Server 2016

A címben szereplő történetben ez nem így történt. Egy picit nehezebb változatát kellett elvégezni a levelezés átpakolásánál, amikor ügyfelünknél igényként felmerült a közös naptárak, értekezletek összehívása, csoportmunka funkciók, teendőlista és egy jól működő, felhasználóbarát adatszinkron (ActiveSync) igénye, így a meglévő linuxos levelezőrendszert egy minden tekintetében modernebb és barátságosabb Exchange levelezőrendszerre cseréltük. A gépek többségén Outlook levelezők voltak IMAP-pal beállítva, a lehetőség tehát itt is adott lett volna, hogy mappánként tegyük át a leveleket, azonban ez a 160-170GB körüli és 30-35 fiók közötti levelezőrendszer esetében nem lett volna járható út. A feladatra 1 hétvégénk volt, hétfőn már a kliensek átállításával kellett kezdeni, hogy a munka ne álljon le a cégnél.

Elsőként feltelepítettük az új szerver gépet, amelyen helyet kapott először egy Active Directory címtár (amellyel korábban szintén nem rendelkeztek) és egy másik virtuális gépen helyet kapott az Exchange rendszer is. Miután a felhasználókat Powershell-ből felvittük, kialakításra kerültek az időközben szintén Excel táblákba felvitt postafiókok is. Az Exchange-et bekonfiguráltuk az IMAP használatához, majd egy kimondottan a migrálás céljára létrehozott felhasználó számára hozzáférési jogot adtunk az új postafiókokra, így egyetlen név/jelszó segítségével lehetőség nyílt a migrálást elvégezni. A közös csatorna, az IMAP tehát megvolt a szerverek közt, már csak a script-eket kellett előállítani. Mivel a linuxos felhasználói fiókok listája és azok jelszavai rendelkezésre álltak, így már az imapsync telepítését követően a forrás szerveren, a linuxon kezdtük el a scripteket kialakítani. A migrálási táblázatból mentett szövegfájl tartalmazta a felhasználónév/jelszavakat, illetve a minden joggal felruházott migráló felhasználó hozzáférését, ami az Exchange oldalról biztosította a jogokat. Az adminisztrátor és néhány korábbi dolgozó levelezésével élesben teszteltük a script-eket még a hétvégét megelőzően, hogy aztán a péntek délután beköszöntével élesben is elindulhasson a script az összes felhasználó fiókján.

Természetesen nem ment ennyire simán minden, már a próba migrálások alkalmával is számos problémával kellett megküzdeni, köztük a Citrix Xen hálózatkezelési bugjával is, ami az amúgy sem túl acélos hálózati kapcsolatot folyton 10MBit-re vette le. Az éles migrálás alatt is jelentkeztek problémák, főleg az átviteli sebességekkel és az ezzel járó időtúllépési hibákkal. Egyes imapsync folyamatok a nagyobb postafiókok esetén rendre leakadtak, így volt fiók, amelyen többször is el kellett indítani a script-et, hogy végül minden átmenjen. A migrálási folyamat minden egyes száláról közben a script jelentést küldött a rendszergazdai fiókba, így folyamatosan nyomon tudtuk követni a folyamatot. Vasárnapra végül az utolsó levél is megérkezett az Exchange-be. Hozzá kell tenni, hogy ez idő alatt aki már ismerte az Exchange webes elérését, esetleg be tudta magának állítani a telefonját az új szerverre az egész idő alatt már tudott küldeni és fogadni is az új szerverről/re.

Hétfőn aztán megtörtént a gépek Windows-os tartományba való beléptetése is, majd az Outlook-ok beállításra kerültek az Exchange használatára. Már a kliensek beállításakor azt tapasztaltuk, hogy a gyakorlottabb felhasználók már az átállás alatt elkezdték használni az új rendszer nyújtotta lehetőségeket, értekezlet összehívásokat, közös naptárakat, egyebeket. A néhány Thunderbird felhasználó számára volt kicsit keserűbb az indulás, nekik végül egy ingyenes bővítmény segítségével sikerült Exchange üzemmódban beállítani a levelezést, amit nem sokkal később a bővítmény fizetőssé válásával az IMAP váltott fel, természetesen így csökkent funkcionalitással. Az átállás viszont teljes győzelemmel zárult, a régi linuxos levelező kiürült, a hétfői induláskor a küldés/fogadás már gőzerővel az új rendszerről futott, ahogyan a régi levelek is mind elérhetőek voltak az új szerveren.

Ekkor még nem tudtuk, hogy ez a munka egy remek főpróbája volt egy fél évvel későbbi nagy migrálásnak, ahol ugyanez volt a feladat, csak nagyban. 500GB levelezés és 200 körüli fiókszám. Mivel itt korábban már az Active Directory rendelkezésre állt így picit módosultak a folyamatok, de alapvetően ugyanaz zajlott. Telepítettük az Exchange Servert (ez esetben már a 2016-ot, ami nem sokkal ezelőtt jelent meg RTM változatban) és beállítottuk. Amikor minden teszt sikeres volt Excelben összeraktuk a migrálási táblát. Mivel nagyon nagy mennyiségű adatról volt szó, és a korábbi tapasztalat az volt, hogy az imapsync sebessége messze elmarad a tényleges hálózati átviteli sebességektől (jellemzően 2-3MB/sec sebességgel csorogtak az adatok a másik helyen), így a projektbe egy plusz csavart is bele kellett vinni. Mivel nem voltunk biztosak abban, hogy a péntek délután-hétfő reggel intervallumban mindent át tudunk másolni, továbbá több dolgozónak is szüksége volt a hétvégén a levelezésére, így kénytelenek voltunk felállítani egy prioritási listát. A tervezés ezen fázisa a helyi informatikával együttműködve történt. A migrálandó fiókokat tartalmazó Excel táblába létrehoztunk egy új oszlopot, prioritás. Nullás prioritás értéket kaptak azok, akiknek hétvégén szüksége van a postafiókjára, ez 2-3 felhasználót érintett. 1-est azok, akiknek hétvégén nem, de hétfőn feltétlen szükség van a levelezésére, ők voltak jellemzően a nagyobb vezetők. 2-est a kisebb vezetők kaptak, akik szintén magas prioritásúak voltak, majd következtek a kevésbé fontos felhasználók és a már nem használt, de még fontos archív leveleket tartalmazó fiókok. Ez utóbbiakat próba migrálásként már csütörtök-péntek folyamán átpakoltuk tesztelve a rendszert és a scripteket. Az 5-6-os (5 – nem fontos, 6 – archív) prioritást kapott dolgozók fiókjai voltak azok, akiknél belefér az is, hogyha a hétfői napon még nem férnek hozzá a leveleikhez. A táblázatba egy script segítségével lekérdezett levélfiók méretek is felvezetésre kerültek, így néhány Excel függvény használatával már láttuk is, hogy az adott prioritású felhasználók összesen hány GB levelezést hoznak át magukkal. Számoltunk vele, hogy IMAP-pal lassú lesz a migrálás, így a prioritásos migrálás bevezetése mellett is volt B terv, szükség is volt rá.

Péntek délutánig átmozgattuk a próbamigrálásra kijelölt fiókokat, amivel a munka néhány százaléka készült el, egyben teszteltünk mindent. Az átviteli adatok itt is adtak okot az aggodalomra, habár az előző munka során a hálózati problémákból eredő időtúllépések itt elmaradtak. Eljött a munkaidő vége, hazament mindenki, kezdődött az éles folyamat. Első körben mentek a 0-ás prioritásúak. Éjfél körül át is értek, ezzel az első és legfontosabb lépés teljesült, ők már szombat reggel tudtak dolgozni az új levelezőrendszerrel. Aztán éjfél után indultak az 1-es prioritásúak, akikből már jóval több volt, és jellemzően nagy postafiókok, így a teljes állomány kb. 25-30%-át ők adták. Szombat reggelre aztán már látszott, hogy ezzel a tempóval kb. 5-6 nap lenne a teljes migrálás, így először be kellett vetni a B, majd a C tervet is, legvégül a menet közben született D tervet is.

A B terv az volt, hogy lassú migrálás esetén a script egy apró módosításával kizárjuk a migrálásból a nagyobb méretű leveleket, azokat egy második körös migrálással pakoljuk át. A módszer működött, a nagyobb méretű csatolmányokkal rendelkező levelek ott maradtak a régi rendszeren, a script pedig lépett tovább és egyre gyorsabban pakolta át a fiókokat. A tempó azonban még így is nagyon kevés volt, becslés szerint jó esetben a 3-as prioritású fiókok végéig jutott volna csak el a script hétfő reggelre. Így eljött a C terv ideje. Ez előtte a másik helyen már kipróbálásra került, ott a hálózati sávszélesség problémája miatt kevésbé, itt szerencsére jobban működött. A két Exchange közötti migrálás adta az alapötletet, ott ugyanis beállítható a rendszerben, hogy egyszerre hány migrálási folyamatot végezzen a gép. Mivel ott a sávszélességet alapból korlátozza a rendszer (hogy közben használni is lehessen akár a levelezést), így nagy mennyiségű levélnél muszáj hozzányúlni, hogy belátható időn belül végezni tudjunk. Az imapsync esetében is működött, a fiókok adatait tartalmazó szövegfájlt több részre, több fájlra bontottuk szét és egyszerre több scriptet futtattunk. A 2 script ugyan nem jelentett 2-szeres sebességet, de kb. másfelet igen, így sokat gyorsult a folyamat. Sajnos nem eleget, így szombat estére eljött a D verzió ideje, a script-ekbe beépítettük, hogy a régebbieket ne pakolja át, csak az x időnél újabb leveleket. Ekkor már a 2-es prioritású fiókokig minden készen volt, szombat este egy újabb script az 1-2 prioritású fiókokból kihagyott nagyobb leveleket is átpakolta, így odáig teljesen meg voltunk. A 3-as prioritástól kezdődően már csak az újabb és kis méretű leveleket szedtük át. Így végül hétfő reggelre már a script-ek az 5-ös prioritással bíró fiókok utolsó leveleit pakolták át, a munkaidő kezdete környékén futtathattuk újra őket az összes fiókon, már kizárások nélkül, ami végül a 3-5 prioritású fiókokon másnap reggelre végzett csak. A jó szervezésnek köszönhetően nem hiányolt senki semmit abban az egy napban, amikor még picit hiányos levelezéssel futott a rendszer.

Itt mivel nagyrészt webes felületet engedélyezett a dolgozóknak a vezetőség, így a hétfő reggel nyugodtabban telt. A hétvége folyamán beállítottunk egy csoportházirendet, ami a felhasználók asztalára ikonként kiteszi a webes felület URL-jét, illetve ezen kívül a kedvencekbe, a start menübe is helyez el linkeket. Bár az ügyfelet felkészítettük rá lélekben, hogy hétfőn még várható leállás, minden bizonnyal nem lesz teljesen készen minden, a jó szervezésnek köszönhetően fennakadásmentesen rajtolhatott az új rendszer, aminek az extra funkcióit sokan el is kezdték még aznap használni.

Aztán kicsivel később többen jelentkeztek, hogy szükségük lenne a korábban beállított levelezőklienseikből (Outlook, Thunderbird), másoknál a webmailből az automatikus kiegészítés elemeire, illetve többen használtak névjegyeket is. Mivel senki nem tudta pontosan, hogy ki hogyan levelezik a régi rendszeren így ezeket az igényeket csak egyenként tudtuk kezelni és bár számítottunk rá és készültünk előre, nem ment simán. A régi webes levelezőt használó felhasználók adatait a Roundcube webes levelezőjük tartalmazta, annak az exportjával nem mentünk sokra. A PostgreSQL adatbázishoz hozzáférve viszont egy szerkesztő progival ki tudtuk nyerni ömlesztve az automatikus kiegészítések és címjegyzék adatait. Egy másik fájlba pedig kinyertük, hogy melyik felhasználóhoz milyen azonosító tartozik. Így volt két fájl, benne ömlesztve az adatokkal. Olyan formába kellett hozni, ami importálható, ha lehet tömegesen az Exchange-be. Kb. 1 órás munkával írtunk rá egy programot, ami szabvány XML-es formába külön-külön fájlokba elmenti felhasználónként az adatokat. Ezt a formátumot aztán egy másik, netről letölthető program már tudta olvasni és konvertálni nekünk PST-be. Amikor készen állt a rengeteg apró felhasznalonev.pst fájlunk, készült rá egy Powershell script, ami szépen betolta mindet az Exchange-be. Ezzel a webmail-esek gondja megoldódott. Az asztali levelező kliensekből érkező adatokat aztán egyesével át kellett alakítani PST-be és importálni azok számára, aki ezt kérte. Nehézkes és fáradtságos munkával, de aztán végül minden megérkezett az Exchange rendszerbe.

FlashCom Powered System

Ennek már másfél éve, az Exchange azóta is néhány apróbb hibát leszámítva közel 100%-os rendelkezésre állással üzemel és teszi a dolgát.

Windows Server 2003 end-of-support migrálás elsők közt az országban

2014-ben nem csak az XP korszaknak lett vége, hanem vele együtt a Windows Server 2003 vonalnak is, a két rendszer terméktámogatása szinte egyszerre járt le. Csak amíg az egyiknél a pánik a felhasználók körében uralkodott, addig a Server 2003 cseréjét mi rendszergazdák sürgettük, tegyük hozzá teljes joggal.

Ügyfelünk is éppen egy ilyennel rendelkezett, egy kb. 6 éves Dell szerveren futtatott egy több sebből vérző Windows Server 2003 SBS Premium változatot. A Premium ugye annyiban tudott többet a sima Standard változatnál, hogy ISA Server és SQL is járt hozzá egy csomagban, ami természetesen nem könnyítette meg a feladatot, de az ISA még jelentősen meg is nehezítette. A feladat pedig nem volt más, mint egy új, stabil alapokra helyezett szerver rendszer felépítése, természetesen a régi adatállományok migrálásával, ami a fájl szerver, Exchange levelezés és egy SAP adatbázis átpakolását jelentette. A választás az akkor legmodernebb Windows Server 2012 R2 (Standard) + Exchange 2013 párosításra esett, amihez beszerzésre került egy megfelelő Dell szerver is.

Szintén nehezítésként a szerver infrastruktúra átpakolásával együtt egy linuxos tűzfal gép is beüzemelésre került, ami a régi ISA szervert hivatott pótolni, illetve a régi PPTP alapú VPN helyett erős titkosítású OpenVPN-t szolgáltat nekik. Az alap rendszert Windows Server 2012 R2 HyperV szerepkörrel és 3db virtuális géppel (2db 2012 R2 és 1db 2008 R2) előre telepítésre került, legfrissebb firmware-ek és driverek fent, eljött hát a péntek délután, kezdődhetett a móka.

Elsőként beüzemelésre került az új linuxos tűzfal, ezzel együtt ki kellett gyomlálni az ISA szerver egyes részeit, ami nem volt egyszerű feladat. Miután a hálózat és a távoli rendszer elérés stabilizálódott távolról folytatódott a projekt a virtuális gépek tartományba léptetésével, majd a tartományvezérlő átpakolásával. Itt jöttek az első hibaüzenetek is, ami egy érezhető hálózati laggolással járt együtt. Ezzel párhuzamosan a migráló alkalmazásokkal átpakolásra került a DHCP adatbázis is, majd kialakításra kerültek az új szerveren a megosztott mappák és a hozzájuk tartozó jogok is beállításra kerültek. A tartományvezérlő átment, indulhattak a fájl szerver adatai. Eleinte feltűnően lassan a sok apró fájl miatt, majd a nagyobbaknál elfogadhatóra gyorsult a másolás. Ezt annyira nem volt idő figyelgetni, mert addigra már a 2008 R2-es virtuális gépen kellett vadul barkácsolni, amit mindössze 1 napos használatra telepítettünk. (Mivel Exchange 2003-ról 2013-ra kellett migrálni, kompatibilitás viszont csak 2 verzióval van lefelé így egy köztes 2010-et is telepíteni kellett, majd duplán migrálni mindent.)

A 2008 R2-es szerverre telepítésre került az Exchange 2010, ahova éjszakára sikerült elindítani a postafiókok adatainak átköltöztetését, ami kb. 20 fiók néhány 10GB-nyi adatát jelentette. A terv eddig apróbb fennakadásokkal, de óraműszerűen működött. A fájl szerver több száz GB-nyi adatának egy része még másolt az egyik virtuális gépen, az Exchange átköltöztetés pedig elkezdődött, hogy aztán pár óra alvás után a kész másolásokkal folytatódhasson szombat reggel a munka.

A projektben a tervezetthez képest a csúszás itt következett be, ugyanis kb. 8 órára rá a másolás közel sem volt kész. Mindössze 5GB körüli levelezés ment át és a fájl szerver adatainak kb. 80%-a. A virtuális gépeken eközben a hálózati kapcsolat katasztrofálisan üzemelt. A hoszt gépről a virtuálisra a ping 10-800ms közötti értékeket dobált, aminek normál esetben 1ms vagy az alatt kéne lennie. Google a barátunk, 1-2 óra keresgélés, barkácsolás után meglett a vétkes és a megoldás is, a Broadcom hálókártya és annak drivere viccelt meg. Hiába a Dell oldalán se volt minden tökéletesen naprakész és mint a netes fórumokról ez kiderült a mi szerverünkben lévő kártya elhíresült egy ilyen problémáról. Végül a tervezetthez képest kicsit később, kb. szombat délre átment minden a 2010-es Exchange-be. Hozzáteszem eközben még az idő nagy részében elérhető is volt a rendszer, több alkalommal láttam, hogy mobilról levelet küldtek az átmeneti szerveren keresztül. Aztán jött a szombat délutáni program, a 2013-as Exchange telepítése a hálózatba, majd a levelek következő migrálása 2010-ből 2013-ba. A gyors hálózatnak hála ez már egy gyorsabb folyamat volt, még ha nem is zökkenőmentes, de szombat késő délután sikerült végül a 2010-es Exchange-et is lebontani a rendszerről, mivel teljesen elkészült az Exchange migrálása. Időközben a fájl szervert is átpakoltuk minden adatával, a megosztások is rajtra készen álltak, ideje volt a csoportházirendek közt is rendet tenni, hogy hétfő reggel felcsatolódjanak a gépekre az új meghajtók. Az önkiállított Exchange tanúsítvány és az Exchange elérés kapcsán is számos finomhangolást el kellett még végezni, de szombat estére már a régi 2003-as SBS szervert is sikerült teljesen lebontani, a tartományvezérlő szerepkör eltávolításával, Exchange eltávolításával és az ISA szerver maradványainak eltakarításával. A tűzfalon időközben elkészítésre kerültek az OpenVPN-hez szükséges tanúsítvány csomagok, amiket az új e-mail címeikre meg is kaptak a dolgozók.

A rendszer készen állt a hétfői indulásra. Előzetes tervek szerint azt ígértük, hogy hétfőre minden szolgáltatás, adat átmegy az új szerverre, az SAP-t és annak adatbázisát az SAP támogatást biztosító céggel közösen oldjuk meg, már hétfőn. Mivel teljesen új infrastruktúra épült ki így számítottunk rá és fel is készítettük az ügyfelet, a hétfő reggeli döcögős elindulásra. A kliens gépek viszont csatlakoztak a hálózatra, be tudtak jelentkezni és látták az új fájl szervert, egyeseknek az Outlook újracsatlakoztatása is gyorsan ment. A zajos hétfő reggel elmaradt, mindenki meg tudta kezdeni a munkát. Egyedül az e-mail fiókok újraállítgatása, az új tanúsítvány elfogadtatása ment nehézkesen, a Windows-os telefonok vagy állítgatás nélkül, vagy minimális ráhatásra már működtek is, ahogy az 1-2 iPhone-ról is ez elmondható volt, az Androidok esetében szinte mindenhol fióktörlés, újra létrehozás oldotta meg a problémát, de délre helyre álltak a mobil elérések is a levelezésben, így hétfő kora délután büszkén jegyezhettük fel, hogy ez egy sikeres átállás volt, ami viszonylag simán ment az összetettsége és bonyolultsága ellenére is.

Volt még slusszpoén az eset kapcsán. A hétfői nap végén a történetben szereplő cég egyik tulajdonosa telefonált főnökünknek, majd egy kissé félreérthető hanglejtéssel annyit mondott a telefonba: “Nem erről volt szó.” Pár másodperc feszült csend után aztán folytatta: “Azt mondtátok hétfőn nem fogunk tudni dolgozni, mert minden ilyen átállásnál vannak fennakadások. Arról volt szó, hogy keddre áll vissza a stabil ügymenet. Ehhez képest szinte semmi leállás nem volt. Nagyon köszönöm, ez nagyon profi volt.”

Aztán hónapokkal később volt még egy slusszpoén a dologban. Egy ingyenes, 2 napos képzésen jártam a Microsoft jóvoltából, amit azért szerveztek, hogy segítsenek az IT szakemberek számára könnyebbé tenni a Windows Server 2003 end-of-support probléma kezelését, megmutatni hogyan lehet a különböző migrálási folyamatokat megoldani. Rengeteg hazai IT nagyvállalat emberei voltak jelen. Lehet nem a legnagyobbak és lehet nem minden cég képviseltette magát, sőt ez biztos. De voltunk 30-40-en a teremben, és amikor megkérdezték ki hajtott már végre sikeres átállást Windows Server 2003-ról 2012-re, egyedül jelentkeztem. Pedig csak a Windowst kérdezték, ott szó nem esett Exchange-ről, ISA szerverről, linuxos tűzfalról, csak egy szimpla Windows-ról és annak a szolgáltatásairól…