Problémamentes átállás Exchange 2010-ről 2016-ra

2018. nyarán kaptunk felkérést nagyvállalati ügyfelünktől, akivel korábban már több nagyobb projekten sikeresen dolgoztunk együtt. Korábban teljeskörű IT auditot végeztünk náluk, ezt követően a szerver rendszerük korszerűsítését és rendberakását, a korábbi Windows Server-es problémáik megoldását is sikerrel elvégeztük. A munka kezdetét egy alapos tervezés, majd az új Dell PowerEdge szerver és a szükséges szoftverlicencek beszerzése követte. Miután ezzel megvoltunk következhetett a tényleges átállás dátumának kitűzése és az előkészületek. Mivel Exchange átállásról, postafiókok migrálásáról volt szó, amivel korábban már számos tapasztalattal rendelkeztünk, így pontosan tisztában voltunk vele, hogy milyen sebességű adatmozgással lehet számolni. Ügyfelünk telephelyén gyakorlatilag a hét minden napján zajlik valamilyen termelő tevékenység, így nagyon fontos volt az átállást a legapróbb részletekig megtervezni, hogy minél kisebb leállással, szolgáltatás kieséssel járjon az egész folyamat. Köszönhetően a korábban szerzett tapasztalatainknak és az alapos tervezésnek ez jobban nem is sikerülhetett volna, de ne szaladjunk ennyire előre…

Exchange Server 2016

Mivel a tervezési folyamat kezdetekor igen jelentős mennyiségű adatról volt szó, ami akár egy teljes hétvégés átállást is igénybe vehetett volna, ismerve az Exchange fiók migráció tempóját (a rendszert úgy tervezték, hogy olyan lassan csorgassa az adatokat, hogy közben az Exchange lassulás nélkül ki tudja szolgálni a kéréseket, tehát használat közben lehessen átállni), ugyanakkor azzal számoltunk, hogy legjobb esetben is péntek estétől hétfő reggelig mindennek át kellene érnie, hogy ne legyenek fennakadások az átállás során. Ezért az előkészítést azzal kezdtük, hogy kiexportáltuk Powershell-ből a meglévő e-mail fiókokat, majd átnézettük a listát az ügyféllel, aki megjelölte nekünk az archiválható fiókokat. Amint ez elkészült csináltunk egy teljes mentést a régi Exchange rendszerről és a levéladatbázisokról (mind a háromról), majd lejjebb vettük az adatmegőrzési időt, hogy az átállás tervezett dátumáig végleg törlésre kerüljenek az adatok. Ezután szintén Powershell-ből a törölni kívánt fiókok tartalmát kiexportáltuk PST fájlokba, majd töröltük (illetve letiltottuk, törlésre megjelöltük) a sikeresen exportált fiókokat. Ezzel a közel 500GB-os levéladatbázisokat 300GB körülre le tudtuk szorítani. Itt alkalmaztunk még egy korábban jól bevált trükköt, minden fiókhoz 1-től 5-ig kértünk egy prioritási számot, hogyha hétfő reggelre bármi miatt nem tud lefutni minden tudjuk kik azok, akiknek feltétlen működnie kell. Az 1-es prioritási csoportba kerültek azok, akiknek hétvégén is el kell tudni érni távolról a levélfiókjukat, a 2-esbe és a többibe pedig fontossági sorrendben bekerült mindenki más.

Az előkészítő munka egyik fontos eleme volt az is, hogy az Outlook kliensek verzióját ellenőrizzük, erre az új Exchange-re való problémamentes kapcsolódás miatt volt szükség. Mivel az ügyfél számára korábban telepítettünk egy WSUS rendszert, így a 2010-es és 2013-as Office rendszerekre és az Outlook-ra kiadott és még nem telepített frissítéseket rövid határidővel telepítettük a gépre és az átállás előtt gondoskodtunk róla, hogy minden gépen olyan verziójú kliens legyen fent, amely képes lesz gond nélkül dolgozni az Exchange 2016-al.

Időközben telepítésre került az új szerver, majd az Exchange 2016 virtuális gépe, a Windows Server 2016 Standard a legújabb frissítésekkel, végül a gépre előkészítettük a kezdéshez az összes szükséges telepítőt. .NET csomagot, különböző szükséges filterek és egyéb Microsoft összetevők telepítőit és természetesen a legújabb Exchange 2016 telepítőt is. Ezután a gép megkapta a telepítéshez szükséges szerepköröket és adminisztrációs eszközöket, konzolokat, így tényleg minden készen állt az Exchange telepítő indítására.

Egyetlen nappal az indulás előtt ismét teljes mentés készült az Exchange 2010-ről, majd következett a Microsoft által is javasolt eljárás, a régi szerver frissítése. Megkapta az Exchange Server is a legújabb update rollup-ot, majd a Windows is a frissítéseit. Ezután következett egy gyors ellenőrzés, minden Exchange összetevő problémamentesen üzemelt, így megkezdhette a régi rendszer az utolsó munkanapját, hogy aztán pénteken a munkaidő végeztével indulhasson az utolsó teljes mentés készítése egy külön kazettára, majd a tartományvezérlő soron kívüli mentése, ezután pedig az átállás.

Telepítettük az Exchange 2016-ot, beállítottuk rajta az alapvető küldési – és fogadási összetevőket, és amikor a gép már készen állt a munkára a tűzfalas csapat fél órán belül átállított mindent nekünk a tűzfalon, így innentől már a 2016-os szerver látta el a fő levelezési feladatot, a régi 2010 pedig mailbox szerverként üzemelt tovább, tárolva a régi levélfiókokat. Beállítottuk itt is a 3 levéladatbázist a szükséges korlátokkal, majd megkezdtük a tényleges adatmigrálást. Itt került elő ismét a bekért táblázat, az 1-es prioritási értékkel rendelkezők levélfiókjai így sikerrel elkezdték a másolást péntek este, hogy szombat reggelre már az új szerverről érjék el a leveleiket. Ismerve az Exchange trükkjeit és hogyan lehet gyorsítani a migrálási folyamatot végeztünk pár módosítást a konfiguráción, ami a másolási sebességet nem emelte meg (arra nem ad lehetőséget a Microsoft), de az egyidejűleg másolható elemek számát és az egyszerre elindítható migrálási szálak számát megemelte, ami végső soron a másolási tempó drasztikus növekedésével is járt. A végeredmény olyan jól sikerült, hogy péntek éjfél körül már a 2-es prioritási értékkel rendelkezők fiókjai kerültek elindításra, és mivel ilyenkor nekünk az ügyfél rendszere, az átállás sikeressége jelenti a legfőbb prioritást, így a munkát végző rendszergazda alvás idejét is a migrációs folyamathoz igazítjuk, az előző néhány óra statisztikája alapján pont annyi migrálási szálat indítottunk el, amennyi még egymást nem akadályozza, ideálisan fut le, de a rendszergazdának is ad kb. 8 óra alvás időt, amíg a szerverek másolnak. 🙂 Nagyjából a becslés stimmelt is, így fordulhatott az elő, hogy a 3-as prioritásúak is lementek reggelre, és a szombati reggeli elfogyasztását követően már a 4-es prioritásúakkal folytathattuk, hogy aztán az 5-ösökkel zárva a sort már szombat kora délutánra lefusson a folyamat legkritikusabb része.

Természetesen ez idő alatt számos konfigurációs feladat is elvégzésre került, többek közt a nyilvános mappák migrálásának előkészítése, az egyéb, kézzel konfigurált küldési összetevők script-elt export/importja, az új Exchange-en a levéltanúsítványok beállítása és a virtuális könyvtárak helyes beállítása, ami a mobileszközök és a távoli elérés számára fontos lépés. Így szombat késő estére az utolsó simítások is elkészülhettek, végül a távoli elérés, a webes levelező és minden fontos szolgáltatás tesztelésre került, majd a régi Exchange 2010 lebontása és eltávolítása a rendszerből szintén megtörtént. Teljes lett tehát az átállás, alig több, mint 24 óra alatt átálltunk közel 150db levélfiókkal, 300GB-nyi adattal.

A munka zárásaként vasárnap délelőtt a helyi IT csapattal közösen végig teszteltünk mindent. Néhány mobileszköz újrakonfigurálására még szükség volt, de alapjában véve a szolgáltatások rendben működtek. Hétfő reggel aztán eljött az éles teszt ideje, ahol az Outlook-ok sikerrel kapcsolódtak az új Exchange szerverre és néhány mobil átállításán és az új webes felületet leszámítva észre sem vették a felhasználók a váltást, pedig nem kevés és nem egyszerű munkák előzték meg az előtte lévő 2 napban az átállást. Természetesen a hétfői napon is személyesen jelen voltunk, hogy bármilyen felmerülő probléma esetén azonnal segíteni tudjunk a helyszínen. Szerencsére nem kellett, így egy remekül sikerült munkát zárhattunk és újabb tapasztalatokat szerezhettünk, ügyfelünk pedig újfent elégedett lehetett az elvégzett munkánkkal.

Milyen vírusirtót válasszak?

A legtöbben akik ma számítógépet használnak már tisztában vannak a vírusok veszélyeivel, ez a cikk most nekik szól és a megfelelő védelem megtalálásában szeretne segítséget nyújtani. Azok számára, akik nem érzik ennek súlyát javaslom előbb ezt a cikket: http://www.itcikkek.hu/informatikai-veszelyek-a-virusokrol/

Vírusirtók

Ma már elmondhatjuk, hogy talán egy fokkal jobb a helyzet, mert a Windows 8 megjelenése óta minden PC-n jelen van egy aktív vírusvédelem a Windows Defender személyében. Így azoknak a gépe is már a telepítés első pillanataitól fogva védve van, akiknek fogalma sincs róla mi is az a vírusirtó. Ráadásul a Windows frissítésekkel együtt a definíciós fájlok is frissülnek benne, így folyamatosan naprakészek lehetünk az újonnan megjelenő kártevőkkel szemben. Ezzel az egyetlen baj, hogy a tesztek alapján kb. 80%-os védelmet nyújt csak, vagyis 1000-ből 200 vírus fog átjutni a szűrőnkön. A sok éves tapasztalatunk pedig az ilyen “gyári” védelemmel ellátott gépeken, hogy be is jön az az 1000-ből 200. Ezzel szemben egy jól megválasztott fizetős (de akár még ingyenes) védelem is képes lehet 1000-ből 990 vírus kiszűrésére. Mivel a zsarolóvírusok és egyéb nagyon kemény károkat okozó kártevők korszakát éljük ezt a veszélyt nem árt komolyan venni bármilyen gépről is legyen szó, az otthoni gépünkről elveszített sok évnyi családi fotó éppen olyan fájdalmas tud lenni, mint a cégünk működéséhez szükséges adatok, amiket hiába őrzünk adott esetben biztonságosan, ha egy vírus utána pillanatok alatt elintézi az egészet.

Cikkünket most két részre bontanám, az első szóljon az otthoni felhasználókhoz, a folytatás pedig az üzleti ügyfelek számára segít majd dönteni. Kezdeném azzal, hogy tudomásom szerint egyetlen ingyenes védelmi megoldás sem legális céges használatra, ezt nem árt tudni. Otthoni felhasználásra viszont mindenki szabadon alkalmazhatja őket, általában azzal szoktak kevesebbet tudni fizetős társaiknál, hogy kémprogramok ellen nem védenek, tehát az olyan programok, amelyek hirdetéseket jelenítenek meg folyamatosan a gépünkön, esetleg az internet használati szokásainkról és egyebekről jelentenek azok szabadon garázdálkodhatnak. Nagyon gyakori még, hogy az ingyenes megoldások mindenféle regisztrációkat követelnek meg, folyamatosan ajánlatokkal bombáznak minket, próbálnak meggyőzni a fizetős változat megvételéről, vagy nem valós fenyegetésekre hívják fel a figyelmünk. Éppen ilyen védelem az Avast is, amelyik egyébként az ingyenesek közt talán most az egyik legjobb, mindössze évi 1 alkalommal meg kell adjuk az e-mail címünket, ami egy gyors és egyszerű regisztrációnak felel meg, cserében egész évben ingyen védi a gépünket, sőt még a kémprogram típusú kártevőkkel szemben is aktív. Ugyanakkor a fizetős védelemre szőtt meggyőzési stratégiát már időnként túltolják a programozók, egy ismerősöm gépén például nemrégiben a fizetős változatban elérhető takarító program megvételéről úgy próbált meggyőzni minket, hogy 160GB-nyi szemetet talált egy olyan gépen, amin összesen 140GB az adat, amiben benne volt maga a Windows rendszer és bizonyíthatóan több tíz GB privát adat is, ami legkevésbé sem tekinthető szemétnek. Mégis, ha valaki ingyenes megoldást keres otthonra, akkor elsőként az Avast-ot tudom neki ajánlani, nem elég, hogy a független teszteken mostanában mindig az élmezőnyben végez, a teljessége miatt (kémprogramot is keres) is jó választás. Csak nem kell készpénznek venni, amikor egyéb veszélyekre figyelmeztet és a fizetős változatot akarja eladni nekünk. Ha már szóba kerültek a tesztek, nos mindenképpen érdemes azok alapján választani. Nem mondom, hogy otthoni felhasználóként az ember órákat böngéssze a független tesztek eredményeit és utána olvasgasson minden tesztelési metódusnak, hogy értelmezni is tudja azokat, ezért vagyunk mi, hogy ezt megtegyük. Ráadásul ahogy az informatikában is minden gyorsan változik, úgy itt is gyorsan változnak a trendek, gyakran évről-évre változik a gyártók sorrendje, amit mezei felhasználóként nehéz is lenne nyomon követni. Például sokan emlékezhetnek, hogy 8-10 éve minden a NOD-ról szólt milyen innovatív, gyors és jó találati arányú termék, azóta pedig hosszú évek óta a futottak még kategóriát erősíti.
Ha valaki otthoni felhasználóként rászánja magát egy fizetős védelemre, akkor az Avast mellett egy GData Antivirust tudok neki javasolni, amit minél több gépre vesz meg annál olcsóbb. 1 gépre évente 6000 forint körül érhető el (ami havi 500ft), de ha mondjuk 3 gépünk van otthon, akkor már évi 4000 forint körül is kijövünk gépenként. Érdemes lehet többen összeállni családon belül és akkor nagyon olcsón lehet egy piacvezető vírusirtónk, ami 1000-ből legfeljebb néhány vírust enged csak át, jó eséllyel egy bekapcsolt viselkedés védelem még azokat is lekapcsolja.

A céges ügyfelek esetében már az ingyenesekről nem beszélhetünk, így jöjjenek a fizetős megoldások és azok fajtái. Itt mindjárt fontos lenne két részre bontani a védelmek típusait, központilag felügyelhető és ún. “otthoni” változatra. Általában azt szoktuk mondani ahol a gépek száma 10 alatt van ott mindegy melyik változatot veszik, 10 gép felett azonban már mindenképpen érdemes elgondolkozni a központilag felügyelhető változaton. Ennek rendkívül egyszerű oka van. A vírusirtó is egy program, aminek ráadásul nagyon fontosak a napi rendszerességű frissítések, ugyanúgy tartalmazhat program hibákat, egyes esetekben leállhat akár a védelem, illetve a másik fontos szempont, hogy amikor biztonsági riasztás történik a felhasználó nem biztos, hogy a legjobb döntést hozza, viszont bármit is kellhet csinálnia a rendszergazdának a védelemmel azt csak a géphez odaülve, a felhasználót a gépétől felállítva tudja megtenni. A központi konzolos megoldásoknál ezzel szemben a frissítéseket egy központi konzol tölti le és terjeszti a hálózat gépei közt, amiken egy ún. ügynök program tevékenykedik és küldi a jelentéseket a központi konzol felé. Így a cég rendszergazdája egyetlen felületen monitorozhatja a védelmeket, és kezelheti a biztonsági incidenseket anélkül, hogy a felhasználókat ki kéne vegye a munkából. Ráadásul pillanatok alatt lehet egy beállítást a cég összes gépén elvégezni és pár percen belül már az összes vírusirtó aszerint működik. Ugyanígy beállíthatóak időzített, központi víruskeresések és bármikor lehet ilyeneket indítani kézzel akár egy-egy gépen külön-külön is vagy egyszerre az összesen. Ezek mind olyan hasznos funkciók, amelyek nagyban növelik a védelmi rendszer hatékonyságát, természetesen egy bizonyos számú gép felett érdemes ilyen fajtát választani. Ma már a nagy gyártók mindegyike rendelkezik ezzel a fajta védelemmel. Technikailag egy központi gépet igényel, nem feltétlenül szervert (bár ha egyébként is van célszerű arra telepíteni), de egy olyan gépet, ami az idő legnagyobb részében elérhető a hálózaton és olyan ember használatában van, aki a központi konzolt fogja felügyelni.

Vírusirtó tesztek

Az pedig, hogy ki melyik gyártó termékét választja már picit vallás kérdése is, mert szoros az élmezőny, de mindenképpen a független tesztekből érdemes tájékozódni az aktuális trendekről. A két legnagyobb ilyen oldal a virusbulletin.com és az av-test.com. Ezek különböző szempontok alapján osztályozzák, pontozzák és minősítik a különböző gyártók termékeit. A szempontok közt szerepel általában a találati arány mellett az erőforrás igény (mennyire lassítja a gépünk), az ismeretlen vírusok elleni védelem, az ismert kártevők elleni védelem (felismerés minta alapján), de még az is, hogy hány false positive-ot (hány hibás felismerést) produkál az adott termék. Mi a Virusbulletin által publikált RAP átlagot szoktuk mérvadónak tekinteni, ami a felismerési hatékonyságot átlagolja, az ismeretlen vírusok elleni védelmet és a minta alapján történő felismerést és az ad egy olyan viszonyszámot, ami megmondja nekünk hogyha egy tetszőlegesen kiválasztott vírussal találkozik a gépünk mennyi esélyünk van egy fertőzésre. Minta alapján ma már a nagyobb gyártók szinte mind hozzák a 100%-ot, a RAP átlag viszont arra is vonatkozik ha én éppen most írok egy friss vírust és ráengedem a védelemre / vagy a netről összeszedek egy pár órán belül megjelent új vírust, akkor milyen esélyeim vannak vele szemben. Az elmúlt évek RAP átlagain pedig jól látszik, hogy a GData megoldása évek óta stabilan az élen van, köszönhetően a nagyon hatékony felismerési megoldásainak, amivel az ismeretlen kártevőket is nagyon hatékonyan szűri ki. Erről érdemes megnézni ezt a videót:

Ezzel szemben viszont sajnos a tapasztalatok azt mutatják, hogy olyan neves gyártók, mint az ESET (NOD) védelme is képes több hónapja ismert vírusokkal szemben végzetesen elvérezni, egyik ügyfelünk a korábban jó pénzért megvásárolt ESET Endpoint Security védelme ellenére is sikeresen el tudott indítani egy májusi megjelenésű zsarolóvírust, aminek az exe-jét egyébként a saját aznapi GData Internet Security védelmünk név szerint azonosított és már a másolás pillanatában lefülelt, esélyünk sem maradt tehát elindítani.
Ezért érdemes olyan védelmet választani, ami hatékonyan megvédi gépünket a mai modern vírusoktól, különben nagy árat fizethetünk érte. Pedig gyakran nem a drágább védelem a jobb, ahogy a mellékelt példa is megmutatta. A GData és az Avast mellett ajánlottak még a Kaspersky, az AVG és a Bitdefender termékei is, kinek mi tetszik jobban. Jelen pillanatban ezek a cégek jelentik az élmezőnyt.

Pár szóban a Kaspersky-botrányról

Néhány napja az a hír tartja lázban a magyar IT világot, hogy a Magyar kormány gyakorlatilag kitiltotta az orosz Kaspersky cég termékeit az állami piacról. A témában rengeteg cikk látott napvilágot számos hírportálon, amiben minden információ jelen van, így csak ezekre kívánunk jelenlegi cikkünkben pár mondatban reagálni.

Kaspersky

Első körben álljon itt az Indexhez tartozó portfolio.hu cikke a témában:
https://www.portfolio.hu/vallalatok/it/letiltja-a-magyar-kormany-az-allami-gepekrol-a-kemgyanus-orosz-virusirtot.5.294746.html

Bár nem mi vagyunk a megfelelő szerv annak eldöntésére, hogy a Kaspersky valóban tartalmaz-e kémkedésre alkalmas elemeket, állítólag a forráskódot hozzáférhetővé tették, így azt bárki hozzáértő elemezheti. Nyilván a magyar állami szervek ezt meg is fogják tenni a közeljövőben, amikor is ki fog derülni az igazság, így ami egyelőre csak figyelmeztetés és ajánlás szintjén történt meg (a Kaspersky termékek kerülését kérik az állami szektorban és jelentési kötelezettséget vezetnek be, ha valaki ezt használja), az akár konkrét tiltásként is megfogalmazódhat, hogyha bizonyítani is tudják az EU és az amerikaiak állításait. Addig viszont bölcsebb ha megadjuk a Kaspersky számára az ártatlanság vélelmének jogát, hiszen ami a linkelt cikkből nem derült ki, hogy bizonyíték egyelőre semmire sincsen.

Én csak azt tudom javasolni a Kaspersky témában érintetteknek, hogy figyeljék a független teszteket, mert a Kaspersky termékeitől jóval jobbak is elérhetőek a piacon, ráadásul jobb árakon is, így lényegében nem is kell állást foglalni, csak egy jobb termékre váltani. Pl. a GData védelmére, aki évek óta nem csak vezeti a teszteket, de ráadásul élen jár az átláthatóságban is, ezzel kapcsolatban érdemes megtekinteni ezt a cikket: https://virusirto.hu/g-data/szigoru-adatvedelem-es-megfeleles/

A Kaspersky témára egyébként reagált is a német gyártó magyar képviselete, tőlük az alábbi levél érkezett a tegnapi napon:

Kedves Viszonteladónk,
A tegnapi napon a Magyar Kormány úgy döntött, hogy kizárja a Kaspersky szoftverét, és felszólítja a költségvetési szervezeteket a Kaspersky lecserélésére.

A cikk elolvasható az IT Café oldalán: https://itcafe.hu/hir/kaspersky_magyarorszag.html

Ezt mi sajnáljuk. Ugyanakkor a vállalatokat nem szeretnénk vírusvédelem nélkül hagyni, így segíteni is megpróbálunk.

Ennek kapcsán, amelyik cég bármilyen üzleti vírusvédelmi licencét szeretné üzleti, központilag menedzselhető G DATA szoftverre cserélni, annak INGYENESEN biztosítjuk a meglévő licencidejére a védelmét, amennyiben ugyanannyi időre elköteleződik a G DATA mellett.
Tehát ha valakinek 1 év van hátra a másik vírusirtó licencéből, akkor 2 éves G DATA licencet állítunk ki a számára az 1 éves áron. Amennyiben valakinek 2 év van hátra a másik vírusirtó licencéből, akkor 4 éves licencet biztosítunk a számára…

Természetesen a Kaspersky forgalmazói jogosan vették védelmükbe a saját terméküket, ezzel kapcsolatban a 2F 2000 Kft. az alábbi levelet küldte a partnereknek:

A 2F 2000 Kft. álláspontja a Kaspersky-kormányhatározattal kapcsolatban

Kedves Partnerünk!

 A Kaspersky Labbal való sokéves együttműködésünk alapján fontosnak érzem, hogy a 2F 2000 Kft nevében is reagáljak a Magyarország Kormánya által 2018. 08. 13-án kiadott kormányhatározatra. Ezt a határozatot a magyar sajtó jelentős része és a blogoszféra is gyorsan felkapta, és “A Kasperskynek befellegzett”, “Magyarországon (is) vége a Kasperskynek”, illetve hasonló címekkel mutatta be, mint a Kaspersky Lab termékeit betiltó rendelkezést.

 A kormányhatározat ezzel szemben NEM tiltja be a Kaspersky Lab termékeit. A határozat első pontja szerint a Kormány egyetért az EU azon törekvésével, amely alapján szükséges a potenciálisan veszélyes eszközök kiszűrése és elhárítása. A szöveg nevesíti is a Kaspersky Lab termékeit. Azonban az utasítások, melyek ezt követik, nem írják elő a termékek eltávolítását: a minisztereket átvilágítás készítésére szólítják fel, illetve jelentési kötelezettséget ír elő ilyen termékek újonnan történő bevezetésekor.

 A Kaspersky termékekkel kapcsolatos legfőbb vád az, hogy a termék alkalmas lényegében bármelyik fájl elérésére, így az orosz titkosszolgálat információszerzésre használhatja fel.
 Ennek a kijelentésnek az első fele természetesen igaz, a kártevő-védelem pontosan ezt kell, hogy tegye: minden állományt, sőt, az állományokon kívül elhelyezkedő tárolóhelyeket is ellenőriznie kell. Ezt teszi a piac valamennyi hasonló terméke. A kérdés tehát nem az, hogy a technológia megvan-e bármilyen adat eléréséhez. Hanem az, hogy előfordulhat-e, hogy egy külső szerv, például egy titkosszolgálat, adatgyűjtéshez használja fel valamelyik gyártó rendelkezésre álló technológiáját. És épp ez a vonatkozás az, amivel kapcsolatban a Kaspersky Lab mindent megtesz, hogy világossá tegye: ilyen nem történhet. Emiatt teszi elemezhetővé a forráskódját és költözteti Svájcba adatközpontját, emiatt működik együtt minden, hasonló ügyeket kivizsgálni képes szervvel. Ilyen fokú transzparenciát, ilyen magas szintű bizalomteremtő lehetőséget semelyik másik gyártó nem kínál.

 A sajtó rendszeresen hivatkozik “korábbi esetekre”, melyekről “mindenki hallott”. Az igazság ezzel szemben azonban az, hogy egyetlen olyan eset sem történt, amikor ez előfordult volna. Az erre utaló cikkekkel kapcsolatban vagy az derült ki, hogy nem is történt illetéktelen adathozzáférés (mint például az elhíresült NSA-alkalmazott esetében), vagy pedig egyáltalán semmi konkrét információnak tekinthető részlettel sem szolgáltak, azaz valótlanságot állítottak, mindenfajta komoly megalapozottság nélkül.

 Ennek fényében meglepett bennünket a Magyar Kormány határozata. Ilyen jellegű bizalmatlanság eddig semmilyen más gyártó semmilyen termékével kapcsolatban sem merült még fel (pedig hadd utaljak az egyik legelterjedtebb asztali operációs rendszer kikapcsolhatatlan adatgyűjtésére, vagy a legnépszerűbb mobil operációs rendszer kéretlen helyadat-rögzítésére, hogy csak két nagyon ismert példát mutassak). Természetesen nagyon komolyan vesszük ezt a lépést. Tartok tőle, hogy lesznek olyan ügyfelek, akiknek a bizalma meginog a termékben, illetve a gyártóban – ez egy ilyen helyzetben elkerülhetetlen. Azonban úgy gondolom, hogy pánikra nincs ok. A termékek használata nem tiltott. A Kaspersky-termékek használatának elterjedtségének felmérését a minisztériumok elvégzik, az esedékes megújítások pedig még csak bejelentési kötelezettség alá sem esnek. Új rendszerek bevezetése sem tilos, igaz, bejelentési kötelezettséggel jár.

 Bízom abban, hogy érveinket – a Ti segítségetekkel – el tudjuk juttatni minden egyes ügyfelünkhöz. Bízom benne, hogy sokan megértik majd: ha ilyen típusú adatlopástól tartanak, akkor pont a Kaspersky Lab az a gyártó, amelyik a legmagasabb szintű bizonyosságot tudja adni azt illetően, hogy termékein keresztül ez nem fog megtörténni. Őszinte véleményem szerint nincs a piacon olyan gyártó és/vagy termék, amelyre áttéréskor csökkenne egy ilyen típusú incidens kockázata, sőt.

 Ezzel egyidőben igyekszünk elérni, hogy elinduljon a kommunikáció a magyar döntéshozók és a Kaspersky Lab között, amelytől azt várjuk, hogy a magyar fél is megnyugtató válaszokat kaphat felmerülő kérdéseivel kapcsolatban.

 Az Európai Unióban egyébként, noha időről időre lendületet kapnak a magyarhoz hasonló gyanúsítások, egy-két kirívó kivételtől eltekintve nem született olyan határozat, amely más gyártókénál kockázatosabbnak ítélte volna a Kaspersky megoldásait. Az Európa Parlament egyik állásfoglalása például itt található. •A Kaspersky Lab termékei továbbra is a legtöbb független minősítés és teszt alapján a legmagasabbra értékeltek
•A legtöbbször feltett, bizalommal kapcsolatos kérdés és válasz
•A Kaspersky Lab hivatalos reakciója a kormányhatározatra
Végül arra szeretnélek biztatni benneteket, hogy használjatok minket: amennyiben ügyfeleitek kifejezik bizalmatlanságukat, irányítsátok hozzánk őket, vagy továbbítsátok kétségeiket hozzánk, hogy meg tudjuk válaszolni azokat. Elkötelezettek vagyunk azt illetően, hogy az elmúlt húsz évben kiépített ügyfélkörötök lehető legnagyobb hányadát segítsünk megtartani, akár személyes közreműködéssel, akár érvekkel, információkkal.

 

A levél tartalmával amellett, hogy szélsőségesen elfogult a saját termékükkel kapcsolatban nagyrészt egyet kell értsünk, kivéve azt a tételt, hogy a Kaspersky lenne a legátláthatóbb és az egyetlen, mert azt mindenki tudja, hogy ebben a formában nem igaz. Ettől függetlenül nem gondljuk, hogy azonnal mindenkinek cserélnie kellene az egyik legjobb vírusvédelmi megoldását, habár létezik tőle jobb is.
Ha valaki mégis így dönt annak ajánljuk figyelmébe a teszteket régóta vezető német GData ajánlatát.

Kriptovírusok: új módszerek, új veszélyek

Korábbi cikkeinkben sokat foglalkoztunk már a vírusokkal és legfőképpen a sokakat érintő, és a modern informatika legnagyobb problémájának tekinthető kriptovírusokkal vagy eredeti angol nevén ransomware-ekkel. Aki esetleg nem tudja miről van szó egy gyors ismétlés. A kriptovírus egy olyan újfajta vírus törzs, amely a mai modern kriptográfiai módszerekre, matematikai algoritmusok alapján történő adattitkosításra épül. Lényegében minden nekünk fontos adatot visszaállíthatatlanul (pontosabban csak a visszaállító kulcs birtokában helyreállítható módon) titkosít a gépünkön. Miután végzett egy üzenet jelenik meg a képernyőn és közli velünk adataink visszaszerzésének módját és azt is hogyan és mennyit kell nekünk ezért fizetnünk. Innen ered az angol ransomware kifejezés, tehát váltságdíjat kér az adatainkért. Sokan azt kérdezik ilyenkor, hogy miért nem kapják el a rendőrök a gonosztevőket, hiszen ez azért mégis csak bűncselekmény. Ez így igaz, de ezeknek a speciális vírusoknak az előzménye volt egy Tor nevű böngésző, amit eredetileg az amerikai hadseregnek fejlesztettek, hogy névtelenséget biztosítson az interneten, illetve megjelentek az ún. kriptovaluták, amikről szintén lehetne egy terjedelmes cikket írni, talán fogunk is. A vírusokkal kapcsolatban azért fontosak csak, mert szintén olyan online fizetési megoldást kínálnak, ami névtelenséget biztosít. Nem tudni a rendszerben, hogy kitől és kinek megy el a virtuális pénz, a gépünkön lévő programból elutaljuk és a címzettnél megjelenik. Rendszerint Bitcoinban szokás váltságdíjat kérni, az a legelterjedtebb és a legmagasabb valódi pénzt érő virtuális valuta.

Kriptovírus

Aztán ezeknél a vírusoknál megfigyelhető egyfajta evolúció is, folyamatosan fejlődnek és amikor az ember úgy érzi már nem tudják semmivel meglepni, újra és újra sikerül nekik. Okos ember viszont más kárából tanul, ezért érdemes lehet elolvasni ezt a cikket.

Minden ilyen cikkben elmondjuk, de sosem elég hangsúlyozni. A megelőzés három legjobb módszere : mentés, mentés, és mentés! Amikor már beütött a baj nem marad más, mint a mentésből visszaállítás. Nagyon ritkák már azok a vírusok, amikben van olyan jellegű szoftver hiba, ami valamilyen kiskaput biztosít, esetleg visszafejtést tesz lehetővé speciális programokkal. Nem árt egy ilyen katasztrófa esetén szakértőhöz fordulni, mert ritka esetben előfordul, hogy van még mit megmenteni. Ez is az evolúciós fejlődés része, hogy ma már ritkák a rosszul megírt vírusok. Általában sebészi pontossággal végzik a dolgukat. Időközben találkoztunk már olyannal is, amelyik lappang a gépen néhány napot mielőtt a legváratlanabb időpontban akcióba lép.

Eleinte a vírusok terjesztése kizárólag e-mail-ben történt, egy spam kampány során sorra küldték a megtévesztő leveleket, benne a vírusos csatolmánnyal. Sok ilyen vírus már abban is továbbfejlődött, hogy miután megfertőzött egy gépet az azon lévő levelezőprogramot felhasználva a talált címlistára terjesztette tovább magát a megtámadott nevében. Aztán legutóbb írtunk a Wannacry őrületről, ami szintén egy újfajta módja volt a terjesztésnek és az eddig talán legkritikusabb támadássorozatot generálta. Ekkor egy Windows-okban használt hálózati kommunikációs protokoll hibáját kihasználva olyan gépekre is vírust tudtak juttatni, amelyeken egyébként senki nem indított el semmit. Védekezni a naprakész vírusvédelem mellett csak a Windows-ok megfelelő frissítésével lehetett. Aztán maradt a hagyományos e-mail-es módszer és a támadások kicsit alábbhagytak, nem találtak ki újat, egészen mostanáig…

Egy ügyfelünk szervere nemrég egy újfajta terjesztési módszerrel kapott el egy veszélyes vírust. Ez esetben a távoli asztal protokollját támadták (RDP), ami ugyan nem újkeletű dolog, de mégis egy picit más volt. Az interneten minden egyes nyilvános IP címet (minden embernek van egy ilyen, aki kapcsolódik a netre) folyamatosan bombáznak robotok (ez alatt jelen esetben egy szoftvert kell érteni) kérésekkel, amiben a gyári alapértelmezett portszámokat (kommunikációs csatornákat) vizsgálják, hogy hol milyen elérhető szolgáltatást találnak. Amikor egy szolgáltatást az internet felől elérhetővé kell tenni, akkor annak portját (csatornáját) meg kell nyitni egy tűzfalon az internet irányába. Ezt a pásztázó robotok észreveszik, majd a szolgáltatás kommunikációs formájának megfelelő üzenetekkel kezdik bombázni. Bejelentkezni próbálnak egészen konkrétan, jelen esetben egy Windows-os távoli asztal szolgáltatáson. Az ilyen, ún. brute force (minden lehetséges jelszót rápróbálnak) módszerekkel szemben szokták azt mondani, hogy bonyolult, kellően összetett (legalább 8 karakteres, kisbetű, nagybetű, szám vagy egyéb karakter) jelszavakat kell használni. Így idő előtt fel fogják adni az ilyen típusú támadásokat és a rendszerünk védve marad. Ezzel ez esetben sem volt gond. A probléma ott kezdődött, hogy az ilyen robotok is tanulnak és elkezdtek szótár alapon, vagyis egy név/jelszó gyűjteményből dolgozni. Ez a módszer sem újkeletű, az viszont mindenképpen az, hogy jól láthatóan begyűjtötték a nyilvánosan hozzáférhető felhasználónév/jelszavakat és annak adatbázisából próbálkoztak, nyilván jóval nagyobb sikerrel.

RDP zsarolóvírus
RDP zsarolóvírus által támadott szerverek, és a támadáshoz használt név/jelszavak

A mellékelt képen is jól látható, hogy a szöveges tartalmak nyilvános és névtelen megosztására szakosodott pastebin.com oldalon közzé is tettek jókora listát azokról az IP címekről és az azokon működő név/jelszó párosokról, amit már feltörtek. Ezen a példán több, mint 8000 feltört rendszer szerepel. Mind olyan IP cím, amit valamely szoftver tárolt jelszavával vagy egy másik gépből kinyert jelszóval törtek fel. Ügyfelünk szerverén ugyanis egy újabb jelenségre lettünk figyelmesek a vírustámadást követően, a vírus saját naplóinak tanúsága szerint egy külön vírus modult szenteltek annak a készítők, hogy a gépen szétnézzen tárolt jelszavak után. Elsőként kiolvasta a Windows-ból a titkosított, tárolt jelszavakat és vélhetően titkosított formában ki is küldte a gépről. Vannak viszont olyan alkalmazások, amikből könnyedén tudnak ilyenkor adatot kinyerni, ilyen például a böngésző, gondoljunk például bele, hogy a Firefox amikor egy kattintással meg tudja nekünk jeleníteni a tárolt jelszavakat, akkor azok mennyire titkosított formában vannak tárolva. A jelszavak betárolása tehát nagyon kényelmes, viszont nagyon veszélyes is lehet. Aztán következő lépésben vírusunk elintézte a fájlrendszerben jelen lévő árnyékmásolatokat, amik egyfajta mentés szerepét is betöltik. Ez sem újdonság, szinte a kezdetektől minden ilyen vírus megteszi ezt még az elején. Aztán jött az adatok titkosítása. Sajnos mivel jelen esetben közvetlenül egy szervert sikerült megfertőznie, így a kétféle mentés ellenére is komoly veszélynek voltak kitéve az adatok. Szerencsénkre, ahogy a korábbi esetekben sem, úgy ezúttal sem történt a legminimálisabb adatvesztés sem, de ehhez egy adag szerencse mellett a gyors reakcióidő is fontos volt.
Amikor azt érzékelték, hogy a rendszerük drasztikusan lelassult egyből jelezték felénk és mivel szerződéses ügyfélről volt szó, így soron kívül meg is kezdtük a probléma vizsgálatát. Amikor kiderült, hogy egy kriptovírus dolgozik éppen a szerveren lévő adatokon, addigra sok mindent el is intézett, a mentéseket tartalmazó különálló HDD viszont teljesen ép volt még, abból tudtunk csinálni végül egy teljes rendszer visszaállítást. A vizsgálathoz használt vírusirtó aznap még tisztának, másnap reggel már vírusosnak azonosította a szemmel láthatóan kártékony elemeket, tehát egy nagyon friss kártevővel álltunk szemben.

Kriptovírus

Az eset több tanulsággal is szolgál. Először is lehet bármennyire jól konfigurált vagy gondozott egy rendszer, bármelyik szoftver elem a tudtunk nélkül üthet hatalmas rést a pajzson. Jelen esetben egy olyan, amúgy nemzetközi nagy multi cég által gyártott szoftver tette ezt meg, amire az ember nem is számítana. Vélhetően a telepítő egy korábbi verziója egy fejlesztő oda nem figyeléséből vagy kényelméből rendszergazdai jogot adott annak a felhasználói profilnak, amit a szoftver telepítője hoz létre a legelején és aminek (nyilvánosan is hozzáférhető) fix név/jelszavával az adatbázist el tudja érni. A rendszergazdai joggal pedig alapértelmezésben együtt jár a távoli asztalhoz való hozzáférés is és máris biztonsági résünk keletkezett. Ezen kívül ha az ember komoly vállalati szintű rendszert üzemeltet (ebben az esetben a szóban forgó program akadályozta ezt meg például, mert összeférhetetlen volt a Windows-os címtárral), ott érdemes fiókzárolást beállítani a végtelen számú jelszópróbálkozás ellen. Vannak a távoli asztal port védelmére szolgáló alkalmazások is, amik szintén csökkenthetik a kockázatot, de mindkét intézkedés akkor ér valamit hogyha amúgy rövid idő alatt generált sok próbálkozásból találnának be. Ezen kívül érdemes csak a szükséges portokat kiengedni a tűzfalon a net irányába, ami olyan azt pedig komoly titkosítással rendelkező VPN kapcsolaton keresztül érni el. Ehhez sajnos célhardver is kell, emiatt a kisebb cégek, otthoni rendszerek esetében nem elterjedt a módszer, de kisvállalati környezetben is tudunk már olyan megoldásokat ajánlani, ami ha kellően jól van beállítva sokat javíthat a védelmen. Itt megjegyezném azt is, hogy az elhanyagolt, hozzáértés nélkül üzemeltetett vagy éppen nem üzemeltetett rendszerek vannak a legnagyobb veszélynek kitéve. Sok esetben pedig akkor fordulnak hozzánk ügyfelek, amikor már mindennek vége. Márpedig egy ilyen támadás egy cég életébe is kerülhet, ha például az összes nélkülözhetetlen adat elveszik. Az otthoni felhasználóknak sem esik jól, ha számukra pótolhatatlan fényképek kerülnek örökre titkosítás alá, de egy cég életében ez sokkal nagyobb tragédia. Ehhez képest elenyésző az a költség, amibe egy adott esetben sokkal tudatosabban üzemeltetett rendszer, a megfelelő biztonsági mentés, tűzfal és vírusvédelem kerül. Ezek mindegyike ha jelen van lényegesen kevesebb az esélyünk az adatvesztésre. Nekünk üzemeltetőknek pedig az a tanulság, hogy nagyon résen kell lenni. Jön egy új program és a tudtunk nélkül olyan jogosultságokat hoz létre, amit nem is gondolnánk. Sajnos időről-időre meg kell vizsgáljuk a rendszerünkben ezeket az elemeket is, illetve ha kell és lehet a gyári alapértelmezéseken is változtatnunk kell. A kriptovírusok úgy néz ki nem csak hogy továbbra is a mindennapjaink részei maradnak, de időről-időre újra próbára tesznek minket és rendszereink védelmét.

Meltdown és Spectre sérülékenység, ami a hírekből kimaradt

Ahogyan a rendszeres olvasók már megszokhatták, nem szoktunk fajsúlyos informatikai témák mellett elmenni szó nélkül. Január elején egy olyan súlyos, processzorokat érintő sérülékenységre derült fény, ami teljes joggal járta be a világsajtót és nagyon sokan foglalkoztak akkor a témával. Éppen a nagy médiavisszhangnak köszönhetően nem éreztük akkor fajsúlyosnak foglalkozni a dologgal, mivel számtalan nagyon jó cikk volt elérhető a neten a témával kapcsolatban. Akik esetleg akkor lemaradtak volna, azoknak ajánlom az alábbi linkeket:
https://index.hu/tech/2018/01/04/ujabb_sulyos_processzorhibat_talaltak_minden_gepet_telefont_tabletet_erint/
http://hvg.hu/tudomany/20180111_microsoft_windows_szoftverfrissites_meltdown_spectre_miert_lassu_a_gepem_2018_benchmark_lassulas_merteke
http://hvg.hu/tudomany/20180108_mit_csinal_a_meltdown_video_intel_botrany

Meltdown

Spectre

A probléma megoldásán persze vélhetően az összes csúcsmérnök megkezdte a munkát az Intelnél, ennek ellenére a megoldás kulcsát a mai napig nem igazán találták meg. Erről szeretnénk most néhány tapasztalatot megosztani az olvasókkal, illetve a cikk első felében összeszedném azokat az információkat, amiket a két hónap alatt eddig megtudtunk a két hibáról.

Először is fontos leszögezni, hogy rengeteg médiában megjelent cikk általánosságban említi a processzorokat, hogy mind sérülékeny, de ez nem teljesen így van. Ugyanakkor az említett két sebezhetőség valamelyike szinte minden felhasználót érint a világban. A Meltdown hibában az Intel által az elmúlt 20 évben gyártott szinte minden (csak néhány korábbi Atom processzor és a rég elfeledett, jellemzően szerverekben használt Itanium kivétel) processzor érintett. Más gyártók a Meltdown problémában nem érintettek. A Spectre sérülékenységnek viszont két különböző fajtája is ismert, ezek közül jelenlegi ismeretek szerint a kevésbé érzékeny 1-es típusban érintett az AMD is, a súlyosabb 2-es típust szintén csak az Intel chipjeiben azonosították. Rossz hír viszont a mobilos felhasználóknak, hogy a jellemzően mobileszközökben jelen lévő ARM processzorok is érintettek a Spectre problémában, ahogyan az NVidia is jelezte, hogy egyes grafikus chipjeivel szintén baj van. A probléma tehát igen súlyos és mindenkit érint a világban, bár nem egyformán, a továbbiakban megnézzük melyik sebezhetőség milyen problémákat vet fel és annak mi a megoldása.

A Meltdown sebezhetőség
Először is kezdeném ezzel a problémával, mivel az Intel által a világ nagy része érintett és ez a hiba ráadásul a súlyosabb. Egyrészt könnyebben kihasználható, mint a Spectre, másrészt a hardveres hiba jellegéből adódóan bármilyen operációs rendszeren fennáll. A nagyobb szoftver gyártók (Microsoft, Apple) már mind adtak ki javításokat rá, hogy a rést befoltozzák, illetve a legújabb Linux kernelek is nyújtanak már védelmet, ezek alkalmazásával is adódnak gondok, de erről bővebben majd a folytatásban. Jelen cikknek nem témája részletesen kitárgyalni a processzorok belső működését, arra rengeteg írás született már a neten magyar nyelven is. Amit esetleg egy átlag felhasználónak tudnia érdemes, hogy a processzorok munkájuk során adatokat töltenek be különböző átmeneti memóriákba (cache), hogy ott dolgozzanak velük. A különböző programok által kezelt minden adat átfut itt, amire most biztonsági kutatók olyan kiskaput találtak, amin keresztül ezek az átmeneti tárolók megcsapolhatóak. Ezért (teljes joggal) a világméretű pánik, mivel az Intel processzorai szinte mindenhol jelen vannak és így a rés is velük együtt. Az AMD tulajdonosok örülhetnek, ők nem érintettek.

A Spectre sebezhetőség
Egy kicsit más jellegű, de szintén a processzorok működési mechanizmusán alapuló biztonsági probléma a Spectre. Egyedül ebben hasonlítanak a Meltdownnal, illetve közös pont még, hogy az Intel processzorai ugyanúgy érintettek benne, ráadásul ők egyedül akik mindkét típusú Spectre támadással szemben védtelenek. A jó hír ezzel szemben, hogy a Spectre sokkal nehezebben kihasználható biztonsági rés és kevésbé kritikus is, illetve szűkebbek a lehetőségek is egy Spectre alapú támadás során. A rossz hír viszont, hogy szoftveresen nem javítható. Tehát ez a probléma egyedül a processzorok cseréjével lesz csak teljes mértékben kiküszöbölhető. Az AMD tulajdonosok ismét örülhetnek, jelenlegi ismereteink szerint ugyanis csak az 1-es számú Spectre támadással szemben védtelenek és azzal szemben is csak egyes Linux változatok gyáritól eltérő kernel beállításai esetén, a 2-es számú egyáltalán nem fut le rajtuk. Ezzel szemben az Intel processzorok minden operációs rendszer alatt érintettek mindkét Spectre támadással szemben. Itt lényegében a felhasználói fiókok és a jogosultságok közötti falat törik át, jellemzően böngészőn keresztül. A processzor egy tervezési hibáját kihasználva úgy fér hozzá egy program kód egy másik adatához, hogy közben a rendszer szintjén nem lehetne ahhoz hozzáférése. A jelenlegi állás szerint erre nem tudnak biztos szoftveres megoldást adni, ugyanakkor a szoftver gyártók és a legelterjedtebb böngészők fejlesztői már adtak ki frissítéseket a szoftvereikhez, amelyek a Spectre ellen hivatottak védeni.

A megoldás: szoftverfrissítés?
A Meltdown problémában a legjobb hír, hogy van rá biztos szoftveres megoldás, sőt már szinte minden rendszerre adtak is ki frissítést. A rossz hír az Intel processzorok tulajdonosainak, hogy az alkalmazása 5-50% közötti lassulást fog jelenteni programtól függően (egyes források szerint 5-30%), ami az olyan rendszereknél, ahol egyébként is nagyon ki van hegyezve a hardver komoly problémákat fog okozni. Ezzel szemben egyes források szerint a problémát a kezdetben kiadott frissítések nem oldották meg, sőt egyéb problémákhoz is vezettek. Egy dolog biztos, hogy több általunk felügyelt rendszeren a naprakész Windows és a konkrét Windows Update csomag telepítése után is sebezhetőnek jelzik a gépeket a tesztprogramok, ami egybevág több szakmai portál információival is, miszerint a hibát azóta sem oldották meg. Csak bízni tudunk benne, hogy az IT történelem legnagyobb biztonsági incidense nem marad hosszú ideig megoldatlan…

Kapcsolódó cikkek:
https://index.hu/tech/2018/01/23/linus_torvalds_az_intelnek_a_hibajavitasotok_szemetre_valo/
http://hvg.hu/tudomany/20180123_intel_processzor_hiba_javitas_frissites_spectre_szoftverfrissites_telepitese
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

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…

Mennyire fontos a mi szakmánk?

Mivel úgy érzem és úgy látom a mai világ egyik legkevésbé megbecsült, megértett és leginkább alulértékelt szakmája az informatikus, ezért a korábbi gondolatébresztő cikk folytatásaként szeretnék valamit ismét átadni azoknak, akik erre fogékonyak és szeretnének valamit megérteni a mi szakmánkból.

Először is kezdeném ott, hogy hiába alulértékelt, ennek ellenére a mai 21. századi világban az egyik legfontosabb szakma a mienk. Ezt lehet vitatni, lehet rajta vitatkozni pro és kontra a végtelenségig, de ettől még tény. Ha veszi a fáradtságot és végig olvassa ezt a cikket az olvasó meg is fogja érteni miért mondom ezt.

Ha Önnek a világ legfontosabb hivatását kellene megneveznie, mi lenne az? Azt hiszem, hogy az orvos. Ha betegek vagyunk, csak Ő segíthet, ha netán élet és halál közt vagyunk az mindent felülír. Ha az élet, az egészség hiányzik nincs értelme semminek. Én az orvosokra szavazok, a legfontosabb hivatás az övék, szerintem ebben a legtöbben egyetértenek velem. Ha életet kell menteni, óvni az egészséget csak rájuk számíthatunk. Természetesen egy orvos is korlátozott lehetőségekkel bír, ha mondjuk visszamegyünk 100 évet az időben. Könyvekből kikeresheti, ami neki éppen kell, a recept íráshoz nem kell neki feltétlen számítógép és sok mindent meg tud oldani anélkül is. Persze az Ő hatékonyságát is nagyban növeli az informatika. Ha ma egyik napról a másikra kivonnánk az informatikát a világból összeomlanának a kórházak és emberek halnának meg. Persze ez csak amiatt van, hogy nagyban támaszkodnak a modern technológiára, ha kell nagyon nehezen, de vissza tudnának állni a középkori szintre. Az ellátást nem tudnák ilyen színvonalon és mértékben megszervezni, rosszabb minőségű ellátással több egészségügyi dolgozóra lenne szükség. Itt már azért érzékelheti a kedves olvasó, amire az elején utaltam, amikor azt mondtam az egyik legfontosabb szakma ez. Az aktuális példa csak egy csepp a tengerben, hogy hogyan és miért könnyíti meg az informatika a napi életünket.
Ha az orvosokat sorolom az első helyre, akkor azt is mondhatom az informatikus a következő a sorban. Nem csak azért, mert az első helyen lévő orvos szakmája is nagyban függ tőle, hanem azért, mert ma már szinte mindenkié. A modern kor legnagyobb kincse, az információ, az adat élete, egészsége felett álló szinte mindenható úr. Ezért is fontos, hogy mennyire becsüljük meg, mert ahogy az orvosok közt is van jó és rossz, ugyanúgy az informatikusok közt is. Ahogyan az egyik felelőtlenül bánik az egészségünkkel, az életünkkel, ugyanúgy a másik az életünket jelentő adatainkkal teszi mindezt.
Sajnos nagyon sok adatok feldolgozásával foglalkozó, azzal pénzt kereső ember, de ami még nagyobb baj még rengeteg olyan döntéshozó is van a mai világban, akik nincsenek ezzel tisztában. Nagyon sok olyan cég van, ahol az informatikára egy szükséges rosszként tekintenek és úgy közelítik meg a rendszereik üzemeltetésének kérdését, hogy mi az a minimum pénzösszeg, amiért a saját adatfeldolgozó rendszerét el tudja működtetni. Nem gondolkozik tovább, hogy esetleg valamiféle védelmi megoldást is ki kellene építeni a már feldolgozott adatok védelmére, gondolok itt vírusirtóra, megbízható hardverre, megfelelő szoftverekre, mentési megoldásokra és az IT hátteret biztosító rendszerek üzemeltetésére. Elvégre veszek egy gépet, rakok rá egy lopott Office-t és máris Word-ben, Excel-ben gyárthatom az adatokat. Aztán majd gondolkodunk utólag, ha valami elveszett, hogyan lehetne visszaszerezni. Vélhetően nagyon drágán vagy sehogy.

Mindenkinek az egészsége mellett a második legfontosabb az anyagi biztonsága. Mégis vannak a 21. században még olyan cégvezetők, akik nem gondolkodnak el azon, hogy az anyagi biztonság egyenlő a vállalkozásom adatainak biztonságával. A képlet nagyon egyszerű. Nem törődtem az adataim biztonságával, az adataim hardver/szoftver/vírus/emberi hiba okán elvesztek. Ha szerencsém van csak olyasmi veszett el, ami pótolható, esetleg fennakadásokat és kiesést okoz, nem jár jelentős anyagi kárral. De az is előfordulhat, hogy a cég csődbe megy ennek köszönhetően. Hozzáteszem azok az emberek, akik így gondolkoznak vagy nem vezetnek nagy cégeket, mert éppen az egyszerű gondolkodásmódjuk okán sose fognak magasabb szintre eljutni, vagy ha egy nagyobb cég vezető beosztásában helyet is kapnak hamar távozniuk kell onnan, mert aki egy magas szintre eljut annak a gondolkodásmódja is sokkal profibb már. Így a felettesük hamar felismeri majd a hiányosságot. Jó esetben, mert azért erre is látunk nap, mint nap példát, amikor komoly cégeknél magas beosztásban vannak oda egyáltalán nem illő gondolkodású emberek.
Egy másik nagyon fontos gondolat, ami rámutat mennyire nem gondolkoznak el sokan az informatika súlyán és fontosságán. Mindenki, aki döntéshozó pozícióban van tegye fel magának a következő néhány kérdést:
1. Mennyit költök havi szinten takarításra?
2. És kényelmi dolgokra?
3. Az autók fenntartására?
4. Biztosításra?
5. Sallangokra?
6. Ezekhez mérten mennyit informatikára?
Persze önmagában így vizsgálva a kérdést nem biztos, hogy jó következtetésre jutunk. Láttunk már nagyon magas összegért kritikán aluli szolgáltatást is, vagy épp fordítva. De általában ahogy a mindennapi életben a boltban kapható termékeknél is lenni szokott, általában az egy személyes kis BT-k és olcsójánosok az elvárható minimum szint alatti szolgáltatást nyújtanak, a jobbak drágábban dolgoznak, de profibb szolgáltatást adnak. A kérdések kiértékelésére visszatérve mindenesetre elmondható, ha valaki a felsorolt pontok némelyikénél kevesebbet költ az informatikai hátterére, annak érdemes lehet újraértékelnie a dolgok fontosságát. Csak egy gyors példával éljek minek egy olyan cégnek profi takarítást végeznie az eladóterében, aki közben pár ezer forintokat megspórolva mondjuk egy vírusirtón másnap elveszti a számlázóprogramja minden adatát, így nincs mivel kiszolgálnia a szép tisztán ragyogó üzlethelységben a vendégeket.
Biztosításra ugyanakkor szinte mindenki költ. Mindenki retteg attól, hogy leég az épület, beázik a tető és elúszik minden, esetleg a drága autóben esik kár egy parkolóban. Mindenre biztosításokat kötünk, fizetünk érte keményen, miközben az egyik legfontosabb és legnagyobb értékre még a legminimálisabb összeget sem akarjuk rászánni. Sokszor egy éves biztosítási díj töredékéből évekre meg lehetne oldani az adatok biztonságos tárolását, ez ugyanakkor sokakat teljesen hidegen hagy. Az is tény, hogy önmagában nem elég akár csillagászati összegekért megvenni a csúcsszuper informatikai rendszereket, azokat üzemeltetni is kell, méghozzá jól. Ehhez nagyon kevesen értenek igazán, sok informatikus érhető el a piacon, jóból viszont nagyon kevés van.
Ha már több ponton az orvosok munkájához hasonlítottuk az informatikust is, itt is van egy újabb párhuzam. Az informatikus szakma is komoly tudást és precizitást igényel. Ahol ez hiányzik nem lesz jó a végeredmény sem. A jó informatikus végeredményben pénzt takaríthat meg nekünk és jobb az elérhető legjobb biztosítási ajánlattól is, amikor az adataink biztonsága a tét. Sokan akkor tudják csak meg mennyire fontos jó kezekbe helyezni a rendszerüket, amikor már megtörtént a baj, mert a legtöbb laikus ugye nem látja addig a különbséget. Az is tény, hogy sok esetben sok jó megoldás is létezik, az igazán jó informatikus pedig ezek közül képes megtalálni a legjobbat.

Végezetül összefoglalva legegyszerűbben úgy is megfogalmazhatjuk, hogy éppen az informatikus szakma az, ami megkülönbözteti a 21. századot a huszadiktól. Semmi sem volt még a történelem során olyan hatással a világra és a benne zajló életre, mint az informatika. Talán az elektromosság feltalálását említhetnénk, de egyedül önmagában az sem változtatta meg ennyire a világot. Nem véletlen ma már a legnagyobb háborúkat is számítógépek mögött vívják és alapvetően megváltoztatja az informatika mindenki életét. Ennek a modern világnak a működtetéséhez pedig informatikusokra van szükség. Nem csak akkor van szüksége a minket körülvevő kismillió rendszernek ránk, amikor baj van és gyógyítani kell, hanem már a hatékony, megfelelő működtetéséhez is szükség van ránk.