V nadpise článku je zámerne vynechané, o aký upgrade sa jedná. Chcete nasadiť novú verziu D2000 na existujúci hardvér? Alebo pripravujete po štyroch (šiestich, ôsmich .. niekedy aj desiatich) rokoch generačnú obmenu železa, prípadne prechod na virtualizované servery v prostredí ICT? Možných scenárov je viacero - poďme sa pozrieť na komplikácie pri testovaní.

Načo

Prvý bod - načo vlastne potrebujeme testovať? Nie je to iba míňanie človekohodín? Z jediného dôvodu - aby bol prechod na nový systém čo najbezproblémovejší. Aby nás nezaskočil nedostatočný výkon CPU alebo diskov, prípadne kapacita pamäte (spôsobené nasadením novej verzie alebo výmenou hardvéru). Alebo nekompatibilita, ktorá vznikla v novej verzii D2000, prípadne v aplikačných skriptoch pri prechode na inu platformu a operačný systém(OpenVMS -> HP-UX alebo HP-UX -> Linux) alebo pri migrácii na inú databázu.
Zároveň je nutné pri plánovaní scenára myslieť na zadné vrátka - každý krok by mal byť reverzibilný, včítane možnosti dosynchronizovania dát (napr. v archívoch alebo MES databáze).

Čo

Zorientovať sa vo veľkom systéme budovanom aj viac ako desať rokov nie je jednoduché. V praxi nám pomohlo vždy udržovať si dokumentáciu o dátových väzbách - a pri plánovaní upgradu ju dôkladne prezrieť a uistiť sa, že je úplná.

Dokumentácia dátových väzieb obsahuje všetky prepojenia systému na okolie:

Komunikácie realizované KOM procesom
Databázové prepojenia - databázy tretích systémov prístupné cez DbManager
Údaje sťahované z webu (http, ftp) - počasie, burzové informácie, komunikácia s partnermi
Údaje získavané a odosielané cez e-mail - výmena správ s okolím, potvrdzovanie transakcié a iné
Komunikácia medzi systémami D2000 (cez Gateway Server + Klient)
Iné komunikácie - napr. web services, realtime rozhrania na burzové systémy typu Trayport

Pred začiatkom testovania je nutné prezrieť všetky komunikačné väzby a uistiť sa, že nový systém (nová verzia D2000 na dočasnom hardvéri, prípadne nový hardvér) bude spustený v dostatočne izolovanom prostredí (napr. vlastná VLAN oddelená od produkcie aj od okolia firewallom), aby nedošlo k neželanému prepojeniu na okolie. V prípade potreby vypnuť automatické štartovanie procesov, ktoré sú za jednotlivé komunikácie zodpovedné (KOM, DBM alebo EVH procesy) a zapínať ich jednotlivo, pri testovaní konkrétnych dátových väzieb.

Čím viac z dátových väzieb sa podarí otestovať, tým je nižšia možnosť nepríjemných prekvapení pri samotnom upgrade. Skúsme sa pozrieť na jednotlivé vymenované položky.

Testovanie komunikácií realizovaných KOM procesom

Vo väčšine prípadov dôkladné otestovanie komunikácií predstavuje problém. Prečo? Jednoducho preto, že zákazník nemá pre každý typ komunikácie testovaciu jednotku, voči ktorej sa dá testovanie vykonať. V niektorých prípadoch je testovanie možné, napr.

Servery schopné obslúžiť viacero klientov (napr. IEC104 server, OPC server a iné) - testovanie priamo pripojením nového KOM procesu k produkcii. Aj v tomto prípade môžu vzniknúť rôzne riziká a problémy. Odporúčame napr. vypnúť alebo odkonfigurovať výstupné merané body nového systému, aby nezačal zapisovať (t.j. otestujeme iba čítanie), prípadne vytvoriť niekoľko meraných bodov, na ktorých je možné otestovať aj zápis (ale nebudú mať vplyv na riadený systém, napr. budú zaslučkované). Ďalej môže byť problém s výkonnosťou hardvéru (dokáže zvládnuť dvojnásobnú záťaž komunikácie?)
Krátkodobé prerušenie komunikácie s produkčným prostredím (po dohode so správcami aplikácie a technológmi) a nadviazanie komunikácie s novým prostredím.
Komunikácia prebiehajúca pomocou súborov - súbory spracované produkčným prostredím je možné duplikovať do nového prostredia

Testovanie databázových prepojení

Toto väčšinou býva menej náročný problém ako otestovanie komunikácií. Použije sa kópia databázy alebo databázovej schémy a sprístupní sa pre nový systém. Následne sa zabezpečí duplikácia dát vkladaných do databázy externým systémom (pomocou triggrov, skriptov alebo dátovej pumpy).

Testovanie údajov z webu

Opäť, pokiaľ sa jedná o jednosmernú komunikáciu (sťahovanie údajov), problémy nevznikajú. Pokiaľ sa jedná o obojsmernú komunikáciu, môže byť riešením nakonfigurovanie testovacieho web/ftp servera simulujúceho produkčný server..

Testovanie komunikácie cez e-mail

Duplikácia e-mailových správ do novej schránky určenej pre testovanie nebýva problémom. Dôležitejšie je obmedziť posielanie správ alebo nakonfigurovať ich presmerovanie tak, aby sa e-maily z nového systému ani náhodou nedostali druhej strane.

Testovanie komunikácií medzi D2000 systémami pomocou gatewayov

Platia podobné zásady ako pri testovaní komunikácií. D2000 Gateway Server zvláda pripojiť viacero klientov (zatiaľ sme v produkcii nezaznamenali výkonnostné problémy). Pochopiteľne treba dať pozor, aby nedošlo k zapisovanu hodnôt novým systémom.

Testovanie iných komunikácií

Tu sa situácia líši prípad od prípadu. Napr. burzový systém Trayport poskytuje prístup do ich testovacieho prostredia, takže je možné dôkladné otestovanie. V rôznych web services záleží od konrétneho výrobcu, resp. od konrétneho zákazníka, či má vybudované aj testovacie prostredie, alebo aspoň podporu pre testovanie v rámci produkcie.

Výkon a funkcionalita

Testovanie výkonu nového systému ako aj jeho funkcionality užívateľmi je takisto dôležité. Ideálne je, pokiaľ dokážeme do nového systému dostať čo najviac dátových tokov z produkcie a vygenerovať čo najreálnejšiu záťaž.

V minuloročnom blogu “Komunikácia v testovacích prostrediach” som popisoval niekoľko možností, ako dostať hodnoty z komunikácií do testovacieho prostredia. Tieto sa dajú použiť aj pri testovaní nového systému:

Simulácia

Najjednoduchšie konfigurovateľná, zároveň najmenej podobná realite :)

KOM replay

Prehrávanie hodnôt nahratých produkčnými KOM procesmi. Tu by som upozornil na jedno obmedzenie, ktoré pri testovacom prostredí nevadilo: formát replay logov sa môže medzi verziami meniť - takže nie je zaručené, že replay logy z produkcie budú použiteľné v novom systéme.

Čo s tým? Dá sa toto obmedzenie obísť? Odpoveď je pozitívna - s trochou snahy sa dá. V najnovších verziách D2000 dokáže nahrávať dáta nielen KOM proces, ale aj Gateway Klient. Takže sa dá k Gateway Serveru produkčného systému pripojiť Gateway Klient (novej verzie). Tento môže bežať v štandardnej konfigurácii a nahrávať štandardnú komunikáciu konkrétneho gateway-a. Alebo môže bežať v transparentnom móde a nahrávať dáta vybraného KOM procesu produkcie. Následne takéto replay logy je možné použiť v novom systéme, keďže sú získané z Gateway Klienta zhodnej verzie, akú má nové prostredie.

Pochopiteľne, nevýhodou KOM replay oproti transparentnému gatewayu je, že sa nejedná o živé dáta, iba o opakovanie nahrávky. Na druhej strane, KOM replay je použiteľný už pri FAT testoch u dodávateľa - a dokonca ešte skôr, pri fáze návrhu hardvérových parametrov. Spustením aplikácie a je zaťažením s použitím replay logov na vývojových serveroch dodávateľa je možné odmerať náročnosť aplikácie (CPU, RAM, I/O operácie) a optimálne a s dostatočnou rezervou navrhnúť hardvér (alebo požiadavky na virtuálne servery v prostredí ICT).

Transparentný gateway

Najkomfortnejšie prepojenie nového systému s produkciou. Ideálne je nakonfigurovať transparentné gatewaye a nechať uživateľom dostatočný čas na vyskúšanie nového systému, ktorý je “takmer živý” - zbiera dáta, archivuje ich, poskytuje užívateľom .. akurát neriadi.
V novembri minulého roka sme nakonfigurovali transparentné gatewaye pri migrácii a upgrade pomerne veľkého zákazníckeho systému. Keďže v ňom bolo niekoľko desiatok komunikačných procesov, aj gatewayov bolo veľké množstvo. Následne v januári tohto roku, pri prechode na nový systém, boli v priebehu niekoľkých minút povypínané KOM procesy starého systému ako aj transparentné gatewaye a pozapínané KOM procesy nového systému.

Nevyhnutnou požiadavkou na nasadenie transparentných gatewayov je ale existencia priameho sieťového prepojeni - takže pokiaľ toto nie je možné (alebo sa jedná o výkonnostné a FAT testy spomenuté vyššie), je užitočný aj KOM replay mód.

Záver

Tento blog si v žiadnom prípade nekladie za cieľ kompletné vyčerpanie témy testovania (na to by bola potrebná monografia, ktorá by vyžadovala zapojenie kolegov z iných úsekov). Chce iba ukázať na niektoré aspekty prípravy výmeny systému, ktoré sme v praxi museli riešiť, a naznačiť spôsoby a cesty, akými sme postupovali.

5.3.2018, Ing. Peter Humaj, www.ipesoft.com

Ako testovať pred upgradom

Peter Humaj