Hosting

Posiadamy wybitnie eksperckie doświadczenie i wiedzę w zarządzaniu systemami operacyjnymi, infrastrukturą sieciową, serwerami aplikacyjnymi oraz bazami danych.

 
 
 

Zajmujemy się hostingiem aplikacji Java Enterprise od 2000 roku. Przez cały ten czas dostosowujemy nasze rozwiązania hostingowe do zmieniającej się technologii i potrzeb Klientów. W trakcie naszej przygody z hostingiem wypracowliśmy własną drogę. Poznaj zasady, którymi kierujemy się oferując usługę hostingu.

Hosting to złożona usługa, na którą składa się wiele elementów. Przedstawimy poniżej te elementy, które występują w naszych wdrożeniach. Rozważając hosting swojego systemu warto wziąć je pod uwagę i przeanalizować pod różnymi kątami:

  • współdzielenia - czy potrzebuję ich na wyłączność,
  • skali - jak dużo ich potrzebuję lub czy w ogóle ich potrzebuję (np. macierz dyskowa),
  • skalowalności - jak szybko mogą zmieniać się potrzeby mojego systemu.

W przypadku krytycznego biznesowo systemu o dużym obciążeniu środowisko hostingowe zapewne będzie potrzebować pełnego spektrum dostępnych środków. W przypadku aplikacji wspomagającej biznes Klienta być może wystarczy współdzielenie zasobów, które pozwoli w pełni wykorzystać zaawansowane mechanizmy bezpieczeństwa i wysokiej dostępności bez potrzeby inwestowania w infrastrukturę dedykowaną.

Bezpieczna kolokacja

Bezpieczna kolokacja, czyli w pierwszej kolejności budynek, który zapewni serwerom i innym urządzeniom obsługującym system:

  • zasoby i parametry środowiska niezbędne do działania, tj. odpowiednią temperaturę i ciągłe zasilanie o odpowiedniej mocy,
  • bezpieczeństwo fizyczne, czyli ochroną przed włamaniem i zdarzeniami losowymi, takimi jak pożar czy zalanie.

Więcej na ten temat w sekcji Bezpieczeństwo.

Łącze do internetu

Łącze do internetu musi umożliwić użytkownikom systemu szybki i ciągły dostęp do aplikacji. Aby spełnić te wymagania centrum hostingowe, w którym znajduje się system, powinno być podłączone wieloma łączami do wielu operatorów zarówno lokalnych, krajowych, jak i operatorów z zagranicy. W zależności od tego do kogo adresujemy system ruch może być prawie wyłącznie krajowy lub w przeważającej części zagraniczny. Warto o tym pamiętać na etapie projektowania ponieważ wpływa to na koszty.

Infrastruktura sieciowa

Infrastruktura sieciowa zapewnia sprawną i wydajną komunikację między internetem a systemem oraz między elementami wewnątrz systemu, np. serwerem aplikacji a bazą danych. Na infrastrukturę sieciową składają się takie urządzenia jak rutery czy przełączniki sieciowe (ang. switch). W przypadku systemów tworzonych przez e-point SA, rutery są częścią infrastruktury centrum hostingowego i są współdzielone przez systemy różnych Klientów. Przełączniki sieciowe to ważny element wprowadzający ład w dalsze elementy infrastruktury. Pozwalają grupować je w wirtualne sieci (VLAN), co umożliwia kontrolę ruchu na poziomie firewalla pomiędzy serwerami podłączonymi do tego samego switcha.

Firewalle

Firewalle zabezpieczają system przed niepożądanym ruchem sieciowym i implementują założoną politykę ruchu sieciowego, tzn. ograniczają komunikację między serwerami do ściśle wybranych protokołów. Firewalle ukrywają przed światem zewnętrznym szczegóły topologii sieci, wykonują translację adresów (NAT), potrafią też wprowadzić priorytety dla wybranego ruchu. W przypadku braku dedykowanych koncentratorów VPN obsługują również kanały VPN. Firewall może też uczestniczyć w bardzo szczegółowym filtrowaniu ruchu np. przez ograniczenie dostępu do panelu administracyjnego aplikacji tylko do określonych sieci, np. siedziby Klienta.

Serwery

Serwery muszą spełnić oczekiwania Klienta i użytkowników dotyczące szybkości działania aplikacji i, co w przypadku systemów internetowych nawet ważniejsze, zapewniając wysoki stopień współbieżności, czyli zdolności do równoległego obsługiwania wielu użytkowników bez znaczącego pogorszenia komfortu korzystania z systemu. W przypadku systemów Java Enterprise ważna jest zwłaszcza odpowiednia ilość pamięci, ponieważ wirtualne maszyny Java (JVM) przechowują sesje użytkowników (w tym kopie sesji z innych serwerów w klastrze) a przy obsłudze każdego żądania HTTP alokują dużo pamięci. Trzeba uważać, aby odśmiecanie pamięci nie było dominującym zajęciem dla procesora.

Systemy operacyjne

Systemy operacyjne to pomost pomiędzy infrastrukturą fizyczną i siecią a oprogramowaniem pośredniczącym i właściwą aplikacją. To system operacyjny przyjmuje pakiety pochodzące z sieci i dostarcza je do konkretnych programów, to system operacyjny obsługuje komunikację z dyskami lokalnymi i pamięcią masową, to system operacyjny jest odpowiedzialny za sprawne zarządzanie dostępną przestrzenią dyskową. I w końcu to system operacyjny wykonuje kod programów, takich jak serwer aplikacji czy baza danych.

Systemy operacyjne są różne. Różną się sprawnością w obsłudze sieci i podejściem do operacji dyskowych, wsparciem producenta i dostępnością oprogramowania. Różnice te decydują o wyborze danego systemu do określonego celu. W e-point preferujemy otwarte systemy operacyjne z rodziny BSD i dystrybucje z jądrem Linux zarówno te komercyjne, jak i darmowe. Nasze doświadeczenie pozwala nam dobrać odpowiedni system do odpowiednich celów. Nie unikamy systemów zamkniętych jeżeli dobrze się sprawdzają w danej roli, np. IBM AIX sprawdza się doskonale jako system obsługujący sieć SAN i bazę DB2 - niewątpliwie pomaga tutaj zupełnie nieprzypadkowa zbieżność producentów. Również systemy firmy Microsoft znajdują u nas zastosowanie, choć tylko z konieczności, jeżeli oprogramowanie potrzebne w projekcie nie jest dostępne na systemach uniksowych. Nie mniej jednak po objęciu ich rygorystyczną polityką bezpieczeństwa i posiłkując się programami pomocniczymi można osiągnąć wysoką dostępność i bezpieczeństwo.

W przypadku Linuksa preferujemy darmowe dystrybucje gdyż nie ustępują w niczym dystrybucjom komercyjnym, a Klient nie ponosi kosztów licencji. Jednak, aby zachować wsparcie producenta na oprogramowanie middleware lub gdy sterownik jest dostępny tylko na wybrane systemy, trzeba użyć dystrybucji wspieranej przez producenta. W takim przypadku rekomendujemy naszym Klientom RedHat Linux.

Oprogramowanie pośredniczące (middleware)

Oprogramowanie pośredniczące, częściej określane krótko middleware jest niezbędne do działania każdego systemu Java Enterprise zarówno dużego, jak i małego. Najczęściej są to trzy pakiety oprogramowania: serwer WWW, serwer aplikacji oraz baza danych.

Serwer WWW

Serwer WWW stanowi pierwszą warstwę, która przyjmuje ruch z internetu do aplikacji. W e-point SA w tej roli występuje Apache - najbardziej rozpowszechniony, stabilny a przy tym bogaty w funkcje i rozszerzenia otwarty serwer WWW. Apache stanowi doskonałe uzupełnienie serwera aplikacji, zajmując się takim aspektami jak:

  • szyfrowanie SSL z certyfikatem serwera oraz z certyfikatem klienta w przypadkach wymagających dodatkowych zabezpieczeń,
  • komunikacja z serwerem aplikacji przez odpowiednie wtyczki, pozwala to odciążyć serwer aplikacji od typowych problemów połączeń sieciowych, co sprzyja optymalnemu wykorzystaniu zasobów serwerów aplikacji,
  • pamięć podręczna (ang. cache) wybranych zasobów dostępnych publicznie.

Serwer aplikacji

Serwer aplikacji wraz z właściwą aplikacją stanowi centralny punkt środowiska hostingowego. To właśnie dla aplikacji zainstalowanej (ang. deployed) w serwerze aplikacji pracują wszystkie pozostałe elementy, obsługując ruch do aplikacji, chroniąc ją lub przechowując jej dane. W e-point SA od wielu lat stosujemy zarówno serwery aplikacji Open Source jak i komercyjne IBM WebSphere i Oracle Application Server.

Od początku towarzyszyliśmy rozwojowi technologii Java po stronie serwera. Początki serwera aplikacji Apache Tomcat sięgają 1999 roku. Nasz pierwszy projekt w technologii nazwanej później J2EE uruchomiliśmy produkcyjnie latem 2000 roku (o początkach Javy Enterprise przeczytaj, tutaj). Obecnie wciąż korzystamy z Tomcat'a, jednak już nie z samodzielnego serwera, ale jako kontenera serwletów osadzonego w JBoss'ie lub w mało znanym, ale zaskakująco dobrym (prosty, szybki, stabilny) serwerze aplikacji J2EE JOnAS.

W największych, krytycznych biznesowo projektach korzystamy z IBM WebSphere. Poważnym użytkownikiem WAS'a staliśmy się przy wersji 4 i kontynuujemy nasze zaangażowanie aż po wersje najnowsze. Posiadamy ekspercką wiedzę w zakresie dużych instalacji klastrowych WebSphere'a (wersja Network Deployment), jego działania, konfiguracji, automatyzacji obsługi, zapewnienia stabilności, migracji między wersjami i koegzystencji wersji oraz monitorowania pracy wszystkich elementów składowych.

WebSphere wdrożony w naszym największym projekcie Amway Online udowodnił uniwersalność technologii Java Enterprise, pokazując w praktyce działanie zasady Write Once, Run Anywhere. Przez pewien okres życia systemu, jeden klaster rozciągał się na serwery Intel z Linuksem jak i IBM POWER5 pod kontrolą systemu AIX. Aplikacja nie wymagała żadnych zmian w związku ze zmianą architektury sprzętowej i systemu operacyjnego. Wykonaliśmy również eksperyment, dodając do klastra kolejne członki klastra, tym razem z węzła działającego pod kontrolą systemu operacyjnego Windows. I tym razem tak heterogeniczne środowisko nie sprawiło niespodzianek - klaster pracował stabilnie a aplikacja bezbłędnie.

Baza danych

Baza danych to w naszych systemach jeden z najistotniejszych elementów środowiska hostingowego. Uważamy, że od czasu opracowania koncepcji relacyjnej bazy danych nie wymyślono nic lepszego w dziedzinie składowania danych. Współczesne systemy Java Enterprise często nie doceniają jak wielką wartość może wnieść do systemu pełne wykorzystanie możliwości bazy relacyjnej. To przekonanie wynika z pracy nad projektami dla naszych Klientów i zaowocowało napisaniem własnego mechanizmu O/R mapping'u pośredniczącego między aplikacją Java Enterprise a bazą danych. Kulminacją naszych doświadczeń jest biblioteka OneWebSQL, którą postanowiliśmy udostępnić jako niezależny produkt.

Podobnie jak w przypadku serwerów aplikacji korzystamy z rozwiązań Open Source i komercyjnych. W naszych rozwiązaniach rekomendujemy bazę PostgreSQL, która oferuje szerokie wsparcie standardów SQL oraz posiada wiele cech właściwych do niedawna rozwiązaniom komercyjnym, takich jak wsparcie dla analizy zapytań, możliwości strojenia, monitorowania, zarządzania fizycznym rozlokowaniem danych a od wersji 9.1 również synchroniczną replikacją danych.

Z rozwiązań komercyjnych korzystamy z bazy Oracle i IBM DB2. Wybór DB2 dla projektu dla firmy Amway i wyzwania, którym musieliśmy sprostać sprawiły, że staliśmy się ekspertami DB2. Potrafimy zbudować i utrzymać wysokowydajną i dostępną architekturę w oparciu o DB2, serwer IBM pSeries z siecią SAN i macierzami dyskowymi, zdolną przetwarzać tysiące zapytać na sekundę.

Warto zwrócić uwagę, że nie zawsze system wymaga drogich i zaawansowanych rozwiązań, takich jak komercyjna baza danych, sieć SAN i macierze dyskowe. Możliwości strojenia współczesnych baz danych Open Source, wydajność lokalnych dysków w serwerach i kontrolerów RAID oraz możliwość cache'owania danych na wielu poziomach sprawiają, że nawet w przypadku krytycznych i obciążonych systemów możemy przeprowadzić kalkulację potrzeb i kosztów, a następnie znaleźć satysfakcjonujące rozwiązanie z punktu widzenia budżetu i wymagań projektu.

Monitoring i profilaktyka

Gdy aplikacja zostanie oddana do użytku w wybranym środowisku hostingowym zaczyna się drugi etap jej życia - utrzymanie. Tutaj muszą ze sobą współpracować dwa zespoły: programiści i administratorzy. O pracy programistów w utrzymaniu aplikacji możesz przeczytaj tutaj, natomiast wyjaśnienia wymaga rola administratorów sieci i systemów.

Nic nie jest wieczne, dlatego w e-point SA nie pytamy czy zdarzy się awaria, ale kiedy się zdarzy. W celu ochrony systemu przed niedostępnością stosujemy trzy mechanizmy:

  • Uprzedzamy awarie - regularnie przeglądamy logi systemowe, stopień wykorzystania zasobów, występujące tendencje oraz monitorujemy w trybie ciągłym wykorzystanie wybranych zasobów (poziom ostrzegania i alarmowy), aby uprzedzić awarię i nie dopuścić do jej wystąpienia. Dzięki tym działaniom możemy w porę:
    • dodać więcej zasobów - pamięci, przestrzeni dyskowej, procesorów, łącza itp,
    • zmienić architekturę klastra np. przez skalowanie pionowe,
    • wymienić sprzęt na nowy już przy pierwszych objawach problemów, przeprowadzić dokładną diagnostykę lub skontaktować się z producentem.
  • Unikamy niedostępności - jeżeli mimo naszych proaktywnych działań wystąpi awaria to chcemy, aby jej wystąpienie nie zaburzyło działania i dostępności systemu. W tym celu budujemy architekturę odporną na awarie, zazwyczaj przez wprowadzenie nadmiarowości (redundancji) na wszystkich poziomach.
  • Wykrywamy awarię - całe środowisko hostingowe, łącznie z aplikacją, jest monitorowane przez 24 godziny na dobę, 7 dni w tygodniu, 365 dni w roku (tak, 29 lutego również). Niezależnie od godziny nasi administratorzy podejmują akcję najpóźniej w ciągu paru minut od otrzymania informacji o awarii. Jeżeli błąd dotyczy aplikacji, to na życzenie Klienta, w przypadku krytycznych systemów, również programiści są gotowi do przystąpienia do działań naprawczych o każdej porze doby.

Monitoring służy trzem celom:

  • Monitorowanie dostępności aplikacji w internecie, w tym poprawności działania krytycznych funkcji biznesowych aplikacji, np. możliwość złożenia zamówienia. Dane z tego monitoringu służą do monitorowania SLA (ang. Service Level Agreement), czyli zakontraktowanej, gwarantowanej przez e-point SA dostępności aplikacji oraz prędkości działania.
  • Monitorowanie dostępności wszystkich elementów środowiska hostingowego, zarówno podstawowych, takich jak serwer, switch, łącze, ruter, jak i oprogramowania, np. serwera www, serwera aplikacji czy bazy danych. Monitorujemy również elementy, które nie leżą w naszym zakresie odpowiedzialności, ale wpływające na dostępność systemu w internecie, np. czas wygasania certyfikatów SSL i poprawność wpisów DNS.
  • Monitorowanie i gromadzenie danych o stopniu wykorzystania wszystkich zasobów, zaczynając od każdego portu w switchu i stanów na firewallu, poprzez wykorzystanie przestrzeni dyskowej, procesora, I/O, pamięci a na wykorzystaniu pul połączeń, liczbie procesów, czasów odśmiecenia sterty przez JVM i wykorzystaniu cache'ów kończąc. Informacje te są niezbędne do okresowej analizy wykorzystania zasobów i uprzedzenia stanów awaryjnych.

Obejrzyj wykład pt. „Monitorowanie pracy serwerów aplikacyjnych J2EE”.

Kopie zapasowe

Wszystkie nasze systemy, nawet najprostsze podlegają polityce wykonywania kopii zapasowych zwanych krótko backupem. Jednak nie każdy system backupujemy tak samo. Różnice wynikają z krytyczności danych i wolumenu (ilości danych). To decyduje o tym czy dany system powinien posiadać dedykowany system backupu z biblioteką taśmową zdolną przechowywać petabajty danych czy wystarczy prosty backup dyskowy.

Przy dużych wymaganiach, dla naszych Klientów budujemy systemy złożone z dedykowanymi serwerami backup'u w dwóch lokalizacjach fizycznych, danymi przechowywanymi w bibliotekach taśmowych i z replikacją danych między lokalizacjami. Całość kontroluje IBM Tivoli Storage Manager.

Przy skromniejszym wolumenie i krytyczności systemów oferujemy usługę backupu w oparciu o backup dyskowy, ale również z replikacją danych do odległej fizycznie serwerowni, pracujący pod kontrolą oprogramowania Open Source, takiego jak Amanda czy Bacula.

Trzeba jednak pamiętać, że wykonywanie kopii zapasowych to tylko połowa sukcesu. Dopiero odtworzenie danych z backupu świadczy o tym, że usługa jest sprawna. Z tego powodu regularnie testujemy podsystem backupu, odtwarzając dane z lokalizacji podstawowej i, co bywa trudniejsze, z lokalizacji zapasowej, symulując niedostępność centrum podstawowego. Wszystko po to, aby być pewnym, że w przypadku konieczności odtworzenia danych z backupu, będzie to możliwe.

VPN

We współczesnych systemach prawie zawsze występuje integracja z innymi systemami. Oprócz wyboru technik i protokołów integracja ma także wymiar hostingowy. W przypadku integracji dostosowujemy się do wymagań Klienta - integracja najczęściej odbywa się kanałem VPN, czasami przez dedykowane łącze o gwarantowanej przepustowości. VPN i łącza stają się kolejnym elementem środowiska hostingowego, które wymagają monitoringu, całodobowego utrzymania sprawności i podjęcia decyzji dotyczących akceptowalnego prawdopodobieństwa niedostępności. W przypadku krytycznych systemów rekomendujemy utrzymanie łącza zapasowego. Inny popularny sposób integracji to integracja po łączach publicznych, bez VPN, ale oczywiście szyfrowanym za pomocą SSL kanałem komunikacyjnym z autentykacją Klienta.

 
 
 

Masz pytanie?

 
 
 
Norbert Pabiś
 
Norbert Pabiś

Dyrektor ds. Realizacji

tel. +48 502 575 516

norbert.pabis at e-point dot pl