reklama
reklama
Biblioteka Wiedzy poleca
Kopia bezpieczeństwa a odzyskiwanie danych w środowisku VMware
Dokument obejmuje zagadnienia związane z praktyczną realizacją kopii bezpieczeństwa środowisk wirtualizowanych o dużej skali wdrożenia. W takich...
pobierz »
Biometria głosowa: efektywność, bezpieczeństwo, łatwość korzystania
Zwiększenie liczby oszustw i kradzieży tożsamości wzbudza coraz większe zaniepokojenie klientów możliwością utraty danych osobowych i poufnych danych....
pobierz »
IBM BladeCenter - IT w pudełku
Rozwiązanie IBM BladeCenter integruje serwery blade, pamięć masową i przełączniki sieciowe w jednej obudowie. Zapewnia przy tym redukcję kosztów...
pobierz »
powiększ tekst 
ARCHIWUM
Przeskoczyć przepaść
4 lipca 2005
Tomasz Marcinek Przykład migracji billingu w Telefonii Dialog SA pokazuje, że niemożliwe jest jednak możliwe.Computerworld — Zmiana systemu billingowego to dla operatora telekomunikacyjnego przedsięwzięcie porównywalne z operacją na otwartym sercu - w obu przypadkach ryzyko jest duże, a ewentualny błąd grozi poważnymi konsekwencjami. W obu także odwlekanie zabiegu powoduje pogorszenie stanu pacjenta, operacja musi więc odbywać się pod presją czasu.
A jeśli, zamiast jednego, trzeba wykonać wiele zabiegów? Przed takim właśnie wyzwaniem stanęła w 2003 r. Telefonia Dialog SA. Firma dokonała migracji aplikacji billingowej do nowej wersji o całkiem nowej architekturze, zmieniając jednocześnie platformę systemową i sprzętową oraz wersję serwera bazy danych.
Rozpoczęty wiosną 2003 r. projekt wymiany systemu billingowego w Dialogu składał się z trzech dużych podprojektów i trwał prawie dwa lata. W ramach pierwszego system Tytan 5.3 działający na platformie HP-UX i współpracujący z bazą danych Oracle 8 zaktualizowano do wersji 6.2, współdziałającej z Oracle 9i. Drugi podprojekt polegał na przeniesieniu systemu w wersji 6.2 z serwera HP Superdome na serwer SunFire E25000 z systemem Solaris 9.
Trzeci etap obejmował wymianę pozostałej infrastruktury - oprócz wymiany serwera, dotychczasowa macierz HP XP 512 została zastąpiona macierzą Sun StorEdge 9990 (de facto HDS TagmaStore), zaś dwa 16-portowe przełączniki Fibre Channel (1 Gb/s) Brocade zastąpiono nowymi - tym razem 32-portowymi urządzeniami z serii SilkWorm 3900 z portami 2 Gb/s. Największym wyzwaniem był pierwszy etap projektu, trwający blisko 15 miesięcy.
Się nawarstwiło
Potrzeba wymiany systemu billingowego wynikała z wielu czynników. Pierwszy i najważniejszy to taki, że w ciągu kilku lat po wdrożeniu dotychczasowego systemu konkurencja między operatorami znacznie przybrała na sile. Jednym z przejawów zaostrzającej się walki o klientów stało się zwiększanie liczby usług, komplikacja taryf i rosnący udział w sprzedaży usług innych niż standardowa telefonia, w szczególności transmisji danych i usług dodatkowych.
<b>Leszek Siwek</b>, dyrektor generalny ds. operacyjnych w Telefonii Dialog SA "W rezultacie zmian rynkowych system realizował znacznie więcej coraz bardziej skomplikowanych przeliczeń, obrósł aplikacjami pomocniczymi, a wolumen danych - związany z wzrostem liczby klientów, ale także ze zwiększaniem się udziału rozliczeń z partnerami biznesowymi i wynikającym z tego wydłużaniem się rekordów billingowych - wzrósł wielokrotnie" - wyjaśnia Leszek Siwek, dyrektor generalny ds. operacyjnych w Telefonii Dialog SA, a wcześniej - w trakcie trwania projektu - dyrektor Departamentu Systemów IT i Billingu.
Wielokrotny wzrost obciążenia uzmysłowił zarządowi operatora, że na dłuższą metę potrzebny jest całkiem nowy system. Ograniczeniem dla wydajności i skalowalności systemu była sama jego architektura, oparta na procedurach składowanych PL/SQL i aplikacjach klenckich Oracle Forms.
Wyzwaniem dla Dialogu zaczęła być także infrastruktura. Każde środowisko sprzętowe działa wydajnie w pewnym przedziale obciążeń. Również jeden z najwydajniejszych na rynku w momencie zakupu serwer HP Superdome z procesorami PA-RISC i macierz HP XP 512 miały pewne granice wydajności transakcyjnej i backupowej. Oprócz tego, wraz z rozrastaniem się środowiska aplikacyjnego współpracującego z systemem billingowym, Dialogowi doskwierać zaczęły ograniczone możliwości skalowania sieci SAN.
Mała zmiana, wielki skok
Choć numery wersji systemu Tytan sugerują, że była to przyrostowa aktualizacja, w praktyce była to całkowita wymiana systemu. "Nie ma takiego aspektu systemu billingowego, który pozostałby w tym projekcie nietknięty. Zmieniło się dosłownie wszystko: filozofia aplikacji i jej architektura, struktura bazy danych, zakres funkcjonalny, możliwości rozbudowy, skalowalność, wydajność, technologia i wygląd interfejsu użytkownika..." - wylicza Leszek Siwek.
Zmiana architektury systemu polegała w pierwszym rzędzie na wyłączeniu komponentów odpowiedzialnych za operacje wymagające intensywnych obliczeń poza motor bazy danych. "Zamiast procedur PL/SQL w wersji 6 stworzyliśmy DPS - Data Processing System - wydzielony moduł obliczeniowy w całości napisany w języku C. W nim przeliczane są dane pochodzące z mediacji, obejmującej wiele usług i obsługujących je systemów źródłowych. DPS wykonuje agregację danych, kojarzy je z taryfami, nalicza upusty itp. Wydzielony proces w ramach DPS odpowiada za generowanie faktur. Baza danych została sprowadzona do magazynu danych, udostępniającego je w różnych układach aplikacjom wewnętrznym, m.in. wspomagających decyzje, sprzedażowym, księgowym, a także operatorom-partnerom" - wyjaśnia Paweł Kłęczek, dyrektor handlowy nadzorujący projekt ze strony Comarch SA.
Dzięki zmianom na poziomie technologii możliwe było znaczące rozszerzenie funkcjonalności systemu. Naczelnym przykładem jest tu nowy moduł służący do definiowania taryf, pozwalający kształtować taryfy, upusty itd. za pomocą wyrażeń regularnych lub poleceń SQL. Jeśli chodzi o elastyczność, zmiana w stosunku do wersji 5 jest tu ogromna - możliwości definiowania grup klientów, pakietów usług, grup rabatowych, schematów rozliczeń są prawie nieograniczone.
"Poprzedni system pozwalał na wiele, ale osiągnięcie tych samych efektów było znacznie trudniejsze, a przede wszystkim ta dowolność mogłaby doprowadzić do przeciążenia systemu. W wersji 6 wydajność nie ogranicza naszych decyzji biznesowych - możemy np. stosować taryfy dynamiczne, czego nie dało się wykonać w wersji 5 Tytana. Mamy także możliwość wygodnego pakietowania i wspólnego rozliczania dowolnych usług. Mamy wreszcie elastyczne narzędzie do rozliczania usług realizowanych wspólnie z partnerami. Dodatkowa korzyść polega na tym, że taryfy zdefiniowane za pomocą nowego narzędzia są czytelniejsze - łatwiej je optymalizować, grupować - słowem, zarządzać nimi" - twierdzi Leszek Siwek.
Migracja z wersji 5 do wersji 6 systemu Tytan miała jeszcze jeden wymiar - Tytan to wprawdzie system oferowany jako produkt gotowy, jednak w przypadku Dialogu liczba modyfikacji w aplikacji podstawowej czyniła go tak naprawdę systemem stworzonym "pod klucz" według indywidualnej specyfikacji klienta. Przenoszenie do nowego systemu funkcji wytworzonych specjalnie na potrzeby Dialog SA okazało się wyzwaniem nawet dla Comarchu, który był autorem aplikacji.
"Żaden inny klient nie zmodyfikował funkcjonalności systemu Tytan tak dalece, jak na przestrzeni lat uczynił to Dialog. Oczywiście, sami w tym pomagaliśmy, ale w momencie planowania procedur migracyjnych i eksportu danych do nowej bazy mieliśmy z tym bardzo dużo pracy. Gdyby nie etap mapowania zmian i modyfikacji, projekt trwałby na pewno kilka miesięcy krócej" - mówi Paweł Kłęczek z Comarchu.
Migracja po kolei
Migracja aplikacji rozpoczęła się od zmiany części mediacyjnej - która w wersj 6 jest jedną z funkcji modułu DPS. Gdy DPS przejął obciążenie obliczeniowe Tytana 5, serwer przestał pracować na granicy wydajności - zyskano czas na dalsze prace.
W następnej kolejności migracja objęła konfigurację taryf, po czym nastąpił długi, trwający kilka miesięcy okres żmudnego przenoszenia definicji procesów biznesowych, między aplikacjami, a także próby przenoszenia danych za pomocą narzędzia stworzonego na potrzeby projektu.
"Jeśli chodzi o przeniesienie danych historycznych, Dialog postawił nam bardzo wysokie wymagania, chciał bowiem zachować spójność opartych na nich analiz i raportów. Jednocześnie jednak czasu na próbne konwersje mieliśmy bardzo mało - ledwie kilka dni w miesiącu. Bez narzędzia przyspieszającego próby nie dalibyśmy sobie rady" - stwierdza Dariusz Jędraszek, dyrektor Działu Produkcji Systemu Tytan w Comarch SA w Krakowie.
| Wydajność z kompilatora
Projektując wersję 6 Comarch założył, że liczba wspieranych platform systemowych będzie duża - obecnie jest ich kilkanaście. W tym celu w Tytanie 6 Comarch stworzył warstwę abstrakcji ukrywającą specyfikę systemu i sprzętu przed wyższymi warstwami aplikacji, dlatego porting nie stanowi dziś większego problemu. "Znacznie trudniejszym zadaniem niż przeniesienie systemu na inną platformę jest sprawienie, by był on na niej równie wydajny. Tu trzeba być kreatywnym, cierpliwym i ostrożnym. Trzeba też mieć odpowiednie narzędzia. Aby zwiększyć wydajność Tytana, w najbliższym czasie zamierzamy eksperymentować z kompilowaniem go za pomocą kompilatorów optymalizowanych pod kątem konkretnych modeli procesorów, wersji systemu operacyjnego i typu aplikacji" - opowiada Dariusz Jędraszek, dyrektor Działu Produkcji Systemu Tytan w Comarch SA w Krakowie. |
| Technologie w projekcie
Aplikacja: migracja z Tytan 5 do wersji 6 - zasadnicza zmiana architektury Baza danych: migracja z Oracle 8 do 9i Platforma: migracja z HP Superdome i HP-UX do SunFire E25000 i Solaris 9 Pamięci masowe: migracja z HP XP 512 do Sun StorEdge 9990 Sieć SAN: wymiana 16-portowych przełączników Brocade (1 Gb/s) na przełączniki 32-portowe (2 Gb/s) |
wydrukuj
Komentarze
Ten artykuł nie ma jeszcze żadnych komentarzy. Twój może być pierwszy...
04-204 Warszawa ul. Jordanowska 12
tel.: (+48 22) 321 78 00 fax: (+48 22) 321 78 88
© copyright 2012 IDG Poland SA
tel.: (+48 22) 321 78 00 fax: (+48 22) 321 78 88
© copyright 2012 IDG Poland SA
