Több szállító cég hosszú és küzdelmes munkája után, az Answare integrátori szerepének köszönhetően, működő rendszerré vált a GKM heterogén szerver és tároló platformja.

A Gazdasági és Közlekedési Minisztérium hitt a szabványos és összekapcsolható rendszerekben. Ezért nem riadt vissza a gondolattól, hogy a Unix szervereihez megvásárolt SAN architektúrájú adattároló platformját a Windows szervereivel is összekapcsolja, ezáltal nagy megbízhatóságú, központilag mentett és menedzselt adattároló rendszert hozva létre. A cél az volt, hogy a Unixon futó vállalati alkalmazáshoz tartozó létfontosságú adatokat és a Windows-os levelező rendszer által kezelt – a minisztérium működése szempontjából szintén létfontosságú – üzeneteket és kapcsolódó dokumentumokat egy közös, magas rendelkezésre állású, a későbbiekben rugalmasan bővíthető adattároló központba vonják össze.

A választás a Sun Microsystems optikai csatolójú 3510FC diszk alrendszerére esett, mivel ez a típus mindent tud, amit ma egy korszerűnek mondható adattárolótól elvárunk: hardveres RAID védelemmel biztosítja az adatok épségét, optikai interfészen keresztül nagy sebességű adatátvitelt nyújt, SAN-ba illeszthető, modulárisan bővíthető, és…  a prospektusok szerint „seamless” módon működik együtt különböző gyártók szervereivel, csatolókártyáival és operációs rendszereivel. Így természetesen a Sun Solaris és a Microsoft Windows felől történő egyidejű elérés sem lehet akadály.

A projekt első fázisa – a Unix szerverek és a tároló összekapcsolása, a SAN kialalkítása, az adatok első körös migrációja – során az Answare közreműködésével ment is minden rendben. Igaz, ekkor még csak egyetlen gyártó termékei működtek a rendszerben. 2004 őszén eljött a továbblépés ideje, és a GKM megbízást adott a csoportmunka alkalmazás korszerűsítését végző beszállítójának, hogy a Windows alapú, a tervek szerint cluster technológiát is használó levelező rendszer szervereit kösse össze a SAN-nal, az adatokat pedig mozgassa át a központi tárolóra. Ehhez először is a hardver összekapcsolását kellett megoldani, amihez a GKM egy másik beszállítójától vásárolt optikai csatolókártyákat a Windows szerverekbe. A kártyák chip készlete és firmware verziója megfelelt a hardver kompatibilitási listán szereplő követelményeknek, bár a kompatibilitás fogalma láthatóan szűkülni kezdett: a Sun a tárolóhoz bizonyos csatolókártyák bizonyos verzióit írta elő, míg a Windows Cluster működése szintén csak bizonyos, a gyártók által tesztelt hardver konfigurációkon garantált. A két lista között nem volt átfedés.

A problémák akkor kezdtek jelentkezni, amikor az alkalmazás-szállító megpróbálta a Windows Cluster telepítése során beilleszteni a tároló alrendszert: a 3510FC rendszertelenül, nehezen reprodukálható módon hibázott. A szállítók közül senki sem tartotta az esetet a felelősségi körébe tartozónak, mert a tároló többször is lefuttatott diagnosztikája szerint belső hardverhiba nem fordult elő, a rendszer a Unix irányából továbbra is tökéletesen működött. Az alkalmazás-szállíttó viszont egy hibátlanul működő „vasat” kért, hogy folytatni tudja a telepítést. A GKM által összehívott beszállítói megbeszélésen megkezdődött az egymásra mutogatás, mindenki a saját maga által képviselt gyártó dokumentumaira hivatkozott, és teljesítettnek tekintette a saját vállalását. A GKM egy időre magára maradt a kiút keresésében, és már a tároló alrendszer teljes cseréjét fontolgatta.

Ebben a helyzetben az Answare a saját szempontjából kockázatos, az eredeti megbízását jóval túlhaladó ajánlattal állt elő. Felvállalta a hiba okának kinyomozását akkor is, ha ahhoz több – esetenként ellenérdekelt, de legalábbis nem az együttműködéséről ismert – gyártó háttértámogatását kell a megfelelően magas eszkalációs szintekig megmozgatni. A munka az érintett gyártók tudásbázisainak összefésülésével indult, majd a Windows Cluster telepítésének tesztelésével, szoftver paraméterezéssel, javítócsomagok telepítésével és további kimerítő tesztekkel folytatódott. Ennek eredményeként sikerült egy hibátlanul működő rendszert előállítani, és az is bebizonyosodott, hogy hardverhiba valóban nem fordult elő.

Az eset klasszikus rendszerintegrációs munkának tekinthető, mégis látványosan rámutatott néhány tanulságra. Egyrészt a mai szoftverek – a legáltalánosabbtól eltérő konfigurációk esetén – még mindig nem telepíthetők „Next-Next-Finish” módszerrel. Másrészt, ha több szállítónak kell egy működő rendszert leraknia, az mindig extra kockázatot jelent az ügyfél számára. Nem lehet olyan pontosan specifikálni a megbízásokban a feladatokat, hogy ne maradnának „szürke” azaz vitathatóan lefedett területek. A rendszerintegrátor tapasztalata és egypontos felelőssége biztosítja azt, hogy a feladat megoldódjék.