Siedem pól bitewnych

Wybór między konkurującymi ze sobą technologiami nigdy nie był tak trudny. Oto nowinki o najważniejszych konfrontacjach.

Wybór między konkurującymi ze sobą technologiami nigdy nie był tak trudny. Oto nowinki o najważniejszych konfrontacjach.

Niektórzy lubią ostrą walkę, inni woleliby coś łagodniejszego. Jedno jest jednak pewne, mnóstwo osób uważnie śledzi potyczki, szukając sposobu, by jak najwięcej zyskać.

Prawie każdy zakup sprzętu czy oprogramowania wiąże się z koniecznością wyboru technologii. Specjaliści od spraw IT starają się zawsze mieć plan awaryjny, aby minimalizować ryzyko nietrafnego wyboru. W kluczowych kwestiach muszą jednak podjąć decyzję: która z konkurencyjnych technologii okaże się dla firmy tańsza, która lepiej zniesie próbę czasu, wreszcie ocenić, czy korzyści z jej wdrożenia uzasadniają koszty tej operacji.

Wybraliśmy najzacieklejsze starcia, którymi na całym świecie pasjonują się tłumy obserwatorów, zmuszonych do decydowania, na które rozwiązanie przeznaczyć pieniądze. Będzie relacja z frontu na linii zmagań Linuksa i Windows, lecz również sporo o tematach mniej głośnych, a może dużo ważniejszych. Porównujemy między innymi: aplikacje WWW z tradycyjnym oprogramowaniem, centralizację danych z bazami rozproszonymi, serwery kasetowe z tradycyjnymi maszynami wieloprocesorowymi, wysoko wydajne połączenia Fibre Channel z internetowym SCSI. Nigdzie nie znajdziesz dokładniejszej analizy, bo każda wymiana ciosów opisywana jest przez eksperta w danej dziedzinie. A kto wie, może w ten sposób ułatwimy ci dokonanie najtrafniejszego wyboru?

Dawid czy Goliat?

Paul Venzia

Najogólniej rzecz biorąc, można oczekiwać zwycięstwa giganta nad rzeszą maluczkich. Może właśnie dlatego firmy wciąż wybierają toporne ośmioprocesorowe maszyny zamiast kasetowych serwerów blade.

Farmę niewielkich serwerów kasetowych łatwiej dostosować do potrzeb uruchamianych aplikacji. Pod warunkiem dobrej współpracy z odpowiednim oprogramowaniem.

Jeśli myślisz o udostępnianiu stron WWW, terminali czy sesji Citrix z "cienkimi" klientami, to nie ma się nad czym zastanawiać: unia maluchów, blade'y czy niewielkie serwery 1U lepiej się nadają do tego typu zadań. Mniejsze ryzyko awarii całego systemu, a oprogramowanie w naturalny sposób dostosowane jest do technologii klastrowej. Łatwiej dopasować moc "farmy serwerów" do faktycznych potrzeb, a w razie potrzeby można ją rozbudować bez rujnowania podstaw systemu. Na dodatek cena pojedynczego urządzenia jest stosunkowo niska, a więc oszczędności wynikające z zastosowania wielu słabszych serwerów zamiast kilku potężnych mogą okazać się duże.

Serwery blade właściwie nigdy nie osiągnęły oczekiwanego przez wszystkich poziomu rozwoju. Początkowe kłopoty z chłodzeniem i dostępem do pamięci zostały już rozwiązane, a przynajmniej istotnie ograniczone, obecnie głównym problemem stało się znalezienie segmentów rynku, w których grupa małych serwerów może konkurować z istniejącymi technologiami, zwłaszcza jeśli chodzi o systemy oparte na Windows. Słabe wyniki sprzedaży kaseciaków są też związane z wszechobecnymi, montowanymi w szafkach serwerami 1U wysokiej mocy. Choć nie dorównują blade'om pod względem możliwości rozbudowy, pozostają nieporównywalnie tańsze.

Nikt jednak nie może ignorować długiej i rozsądnej tradycji umieszczania najistotniejszych serwisów na ogromnym serwerze i kolekcjonowania w ten sposób nagród za wydajność i niezawodność. Oczywiście, do takiego wyboru równie dobrze może zmuszać nas producent oprogramowania. Przecież to właśnie dostęp do aplikacji przeznaczonych do uruchamiania na serwerze ma decydujący wpływ na wybór - i w tej dziedzinie blade ma za słabą renomę.

Brakuje tylko prawdziwej wirtualizacji procesorów. Zazwyczaj każdy mały serwer w "farmie" samodzielnie wykonuje odpowiednio podzielony kawałek kodu, komunikując się z centralnym, wspólnym zbiorem danych. Prawdziwa wirtualizacja wymaga współpracy na wyższym poziomie i bardziej elastycznego podziału zadań. Ta sama aplikacja powinna być równocześnie wykonywana na wielu jednostkach niewielkiego węzła serwerów. Szkoda, że to dopiero melodia przyszłości, bo cena przemawia na korzyść blade'a. Ośmioprocesorowy serwer 7U na bazie jednostek Xeon 3 GHz, dysków 36 GB i 32 GB RAM to wydatek rzędu stu tysięcy dolarów, nie licząc kosztów oprogramowania. Zestaw ośmiu dwuprocesorowych serwerów blade o analogicznej specyfikacji kosztuje, wraz z całą szafką około 65 tysięcy. Oczywiście chcąc uruchamiać aplikacje nieprzystosowane do architektury klastrowej, trzeba znaleźć pieniądze na kolubrynę i o żadnych oszczędnościach nie ma mowy.

To właśnie główna przeszkoda w rozpowszechnieniu serwerów blade: brak oprogramowania wykorzystującego w pełni możliwości tej technologii. Idea centrum danych jako elastycznego urządzenia, w którym moc obliczeniowa procesorów jest przydzielana aplikacjom w miarę potrzeb to wspaniały pomysł. Hardware jest gotowy, lecz software najzwyczajniej nie. I nie zmieni się to, dopóki wielcy producenci - choć prawdę mówiąc, dotyczy to również mniejszych - nie pozbędą się nawyku zalecania, aby tworzone przez nich aplikacje uruchamiać na serwerach-olbrzymach. Do tego potrzeba jednak wprowadzenia na rynek przejrzystych rozwiązań klastrowych, które mogliby obsługiwać dostawcy oprogramowania.

Kiedy dostosowanie aplikacji do obliczeń rozproszonych stanie się normą, a idea abstrakcji jednostek obliczeniowych będzie tak zwyczajna, jak CD-ROM-y, piewcy technologii klastrowej osiągną sukces, a blade'y - jakkolwiek będą wtedy nazywane - opanują rynek.

Konsolidacja a federacja

Doug Dineley

Czy lepiej scalić bazy danych w jedną, czy łączyć je bez gruntownych zmian struktury?

Do dużych korporacji spływają rozmaite dane z setek firm - dostawców, odbiorców, pośredników i partnerów, z różnych regionów świata, z wielu gałęzi przemysłu. Uzyskanie czytelnego, spójnego zestawienia tych wszystkich informacji naraz pozwoliłoby z pewnością lepiej zrozumieć, co chodzi jak w zegarku, a gdzie zgrzyta - sprzedaż, serwis, produkcja. Chcąc sobie z tym poradzić, stajemy przed fundamentalnym pytaniem: czy połączyć wszystko w jedną dużą i spójną bazę, czy zaimplementować rozwiązanie federacyjne, pozwalające uzyskiwać informacje z danych z tego miejsca, gdzie się aktualnie znajdują.

Dawniej przeważająca większość opowiadała się za konsolidacją. Jednak pomysł federacji przebył ostatnio długą drogę, zmieniając się na korzyść dzięki usprawnieniom w profilowaniu danych (data profiling) i zarządzaniu metadanymi (metadata management), nowym poziomom abstrakcji platformy sprzętowej i oprogramowania oraz nowym metodom głębszego przeszukiwania. Obecnie rozwiązania federacyjne pozwalają na powiązanie starej bazy z danymi uzyskiwanymi na bieżąco z systemów transakcyjnych, i to bez problemów związanych ze zmianą platformy.

W praktyce bardzo dobrym pomysłem okazuje się połączenie obu metod. Nawet Oracle, najżarliwszy obrońca idei centralizacji danych, przyznaje, że federacja musi być częścią każdej strategii biznesowej. IBM zaś, największy adwokat federacji, nie pozostaje ślepy na konsolidację danych. Różnica polega na różnym rozłożeniu akcentów: według Oracle 80 procent wysiłku powinna pochłaniać konsolidacja, a 20 - federacja, a IBM widzi te proporcje odwrotnie.

Decyzja o połączeniu baz danych wynika, zdaniem Oracle, ze zdrowego rozsądku. Im mniej kopii w różnych miejscach, tym bardziej przejrzyste dane i lepsza informacja. Konsolidacja umożliwia ciągłe zarządzanie firmą, bez nieustannego wprowadzania zmian. Jeśli operuje się jednolitą bazą, można monitorować bieżące dane, analizować przeszłe i przewidywać przyszłe jednym zestawem narzędzi, bez nadmiernie rozbudowanej infrastruktury.

Federacja zaś oznacza ciągłe gonienie za własnym ogonem. Ponieważ biznes zmienia się bez przerwy, Oracle twierdzi, że większość uaktualnień federacyjnej bazy danych jest przestarzała już w momencie wprowadzania zmian, co uniemożliwia sprawne zarządzanie każdym bardziej złożonym systemem federacyjnym.

IBM odpowiada, że scentralizowane bazy danych byłyby świetnym rozwiązaniem, gdyby można było je uzyskać, ale świat zdąża w przeciwnym kierunku. Wystarczy się rozejrzeć. Największe projekty technologii informacyjnych - na przykład inteligentnych identyfikatorów RFID - zakładają generowanie ogromnej ilości rozproszonych danych. Firmy nie mają wyboru, muszą rozwiązać problem heterogeniczności.

Według IBM, Oracle sprzeciwia się naturalnemu porządkowi rzeczy, wyolbrzymiając trudności i koszty nieustającej walki z narastającą entropią danych. Przenoszenie danych i aplikacji na jedną platformę jest nie tylko pracochłonne i kosztowne, lecz wiąże się z ogromnymi problemami logistycznymi, kłopotami z kompatybilnością oprogramowania - jak choćby aplikacji do analizy zbiorów danych - i użeraniem się z użytkownikami w sprawie terminu wprowadzenia zmian. Dla osób korzystających z bazy danych w swojej pracy na bieżąco żaden moment nie jest odpowiedni na konsolidację.

Te argumenty mogą się wydawać zbyt ogólne, ale opracowano już dwie metody pozwalające lepiej zanalizować dane przedsiębiorstwa i przyspieszyć wyszukiwanie informacji. Obóz federacyjny, reprezentowany przez IBM, skupia się na sposobach wiązania ze sobą heterogenicznych źródeł danych i optymalizacji zapytań obejmujących wiele systemów. Oracle i zwolennicy konsolidacji za cel stawiają sobie utworzenie standardowej platformy baz danych i dostarczanie metod przenoszenia danych między bazami różnych typów.

Oczywiście przedsiębiorstwa IT nie mogą sobie pozwolić na skupienie się, tak jak IBM i Oracle, na konsolidacji czy federacji. Muszą wybierać odpowiednie narzędzia - a raczej kombinacje narzędzi - odpowiednie do swoich potrzeb. W praktyce decyzja bardziej zależy od kompatybilności z istniejącą architekturą i od umiejętności pracowników niż zaangażowania w jedną czy drugą ideologię.


Zobacz również