Początki rozwoju serwisu
Nowo pojawiający się serwis odwiedzany jest zazwyczaj przez niewielką liczbę użytkowników, a co za tym idzie problem generowanego przez niego obciążenia CPU, zużycia pamięci RAM czy obciążenia systemu dysków jest niezauważalny. I tak wygląda sytuacja dopóki nie wystąpią problemy z wydajnością, szybkością działania, otwierania stron itp.
Twórca zazwyczaj dąży wszelkimi sposobami do tego, aby jego strona była jak najbardziej znana i jak najczęściej odwiedzana. Wraz ze wzrostem ilości odwiedzin zaczynają pojawiać się problemy. Hosting współdzielony już nie wystarcza. Konieczne jest przejście na VPS, potem serwer fizyczny. Okazuje się, że pojedyncza maszyna także nie wystarcza, a rozdzielenie WWW od bazy danych rozwiązuje problem jedynie chwilowo. Zaczynają się próby modyfikowania kodu, usuwania części funkcji, które najbardziej obciążają serwery. Problemów tych można uniknąć jeśli jeszcze na etapie wyboru systemu CMS, jako jedno z kryteriów wyboru uwzględnimy to, jak dany CMS potrafi sobie radzić z obsługą większego ruchu.
Na co zwrócić uwagę?
Jak najprościej zwiększyć wydajność? Do jednego serwera dostawić drugi. Jeśli to nie wystarczy, dostawiamy trzeci i następne - tworzymy klaster. W efekcie podjętych działań uzyskujemy większą wydajność (więcej serwerów obsługuje nasz serwis), a także większe bezpieczeństwo (awaria jednej maszyny nie powoduje przerwy w działaniu serwisu).
Opisana powyżej konfiguracja sprowadza się do uruchomienia kilku instancji serwisu na kilku serwerach. Użytkownik, odwiedzający różne strony w ramach danej witryny, trafia na różne serwery. Istotne jest to, aby przejście z jednej maszyny fizycznej na drugą było dla niego płynne i niezauważalne. Aby osiągnąć taki efekt, musi istnieć możliwość wymiany części danych pomiędzy poszczególnymi instancjami serwisów. Te dane to np. dane o sesjach, pliki tymczasowe, przekompilowane elementy stron, szablony, dynamicznie tworzone pliki graficzne.
Czy te wszystkie współdzielone dane znajdują się w jednym miejscu?
W jaki sposób przechowywane są dane o sesjach?
Czy jest możliwość wykorzystania memcached do tworzenia cache sesji i zapytań do bazy danych?
Jeśli wszystkie serwisy odwołują się do jednej bazy danych, to w jaki sposób dany CMS z nią współpracuje?
Jaki jest stosunek zapytań typu SELECT do zapytań typu INSERT, UPDATE, DELETE?
Wystarczy replikacja (jeden serwer obsługuje zapytania modyfikujące dane, a pozostałe odpowiadają na SELECT'y) czy też koniecznym jest zastosowanie klastra?
Jaki CMS?
Jednym ze znanych i dosyć powszechnie stosowanych systemów CMS jest eZ Publish. CMS ten od pewnego czasu udostępnia opcję działania w klastrze, aczkolwiek dopiero od wersji 3.10 można mówić o wygodnym działaniu w takim środowisku. Do wersji 3.7 włącznie jedyną możliwością przechowywania plików było przechowywanie ich lokalnie. W tej sytuacji przygotowując klaster należało zwrócić szczególną uwagę na to, w jaki sposób zorganizować współdzielenie plików cache, szablonów, plików graficznych itp. Testy wykazują, że w przypadku sporego serwisu jedyną opcją jest przygotowanie osobnego, współdzielonego przez wszystkie serwery dysku sieciowego, podłączonego do serwerów szybką i dedykowaną siecią.
Najnowsze wersje eZ Publish wszelkie współdzielone dane przechowują w bazie danych.
Wszelkie dane o sesjach trzymane są w osobnej tabeli. Pliki binarne oraz zawartość stron także przechowywana jest w bazie. Ułatwia to sprawę utrzymania porządku, natomiast generuje dodatkowe obciążenie dla serwera bazodanowego.
Zaletą jest to, że eZ natywnie wspiera replikację baz danych - wewnątrz CMS'u definiujemy serwer główny, do którego wysyłane są wszelkie modyfikacje struktury bazy, definiujemy też serwery dodatkowe, które obsługują zapytania typu SELECT (tylko odczyt danych). Na ten moment wersja klastrowa CMS'a współpracuje jedynie z MySQL, co może być traktowane jako pewna wada. Podczas korzystania z eZ Publish należy szczególnie zwrócić uwagę na to, aby zainstalowana była jak najnowsza wersja CMS'u. Z każdym nowym wydaniem pojawiają się dodatkowe udogodnienia dotyczące działania w klastrze i poprawy zachowania się systemu CMS podczas pracy pod dużym obciążeniem.
Innym powszechnie stosowanym systemem CMS jest Drupal. Jest on bardzo dobrze przygotowany do działania w środowisku klastra i w bardzo prosty sposób się skaluje. Rozbudowę infrastruktury serwisu zacząć można od osobnego serwera na bazę danych i na wszelkie współdzielone pliki. Najprostszym, a za razem skutecznym rozwiązaniem jest tu udostępnienie wszelkich współdzielonych danych jako udziały NFS (Network File System). Dzięki takiej konfiguracji, w razie zapotrzebowania na wzrost mocy obliczeniowej, bardzo prosto jest przejść do dalszych kroków.
Kolejnym etapem będzie rozłożenie obciążenia generowanego przez skrypty php na kilka serwerów fizycznych. Można to zrealizować korzystając z serwera proxy, który będzie przyjmować połączenia, a następnie będzie je przekazywać do farmy serwerów obsługujących generowanie zawartości strony. Na tych serwerach przygotowane są instalacje CMS'u, a także podmontowany jest udział NFS. Wszystkie pliki, które muszą być współdzielone pobierane są z jednego miejsca. Poza obciążeniem generowanym przez WWW zostaje jeszcze obciążenie serwera bazodanowego. Drupal niestety nie jest przewidziany do współpracy z natywnym dla MySQL rozwiązaniem klastrowym (NDB cluster), natomiast przy pomocy mysqlproxy i memcached można tą wadę obejść.
Joomla - kolejny znany i powszechnie stosowany CMS. W jego przypadku trochę jeszcze brakuje do wygody i elastyczności jaką oferują dwa poprzednie systemy CMS. Joomla może być rozbijana na kilka serwerów WWW obsługujących przychodzące wywołania (także z współdzieleniem plików przez zewnętrzny udział dyskowy - NFS czy jakiegoś rodzaju SAN), kłopotliwa jest jednak obsługa paneli administracyjnych serwisu. W przypadku rozbicia niepoprawnie działa obsługa sesji, przez co praca administratora wiąże się z częstymi wylogowaniami. Co ciekawe, obsługa sesji po stronie użytkownika serwisu działa poprawnie. Dodatkową wadą jest brak sensownej obsługi replikacji bazy danych. Jakkolwiek można podać kilka serwerów baz danych, z jakich CMS ma korzystać, to wszystkie te serwery traktowane są też jako serwery do zapisu. Istnieje możliwość obejścia tego problemu, ale wiąże się to z zaawansowaną modyfikacją kodu Joomli.
Dwa z zaprezentowanych powyżej systemów zarządzania treścią można swobodnie określić jako systemy klasy enterprise. Joomla niestety jeszcze nie zasługuje na takie miano. W obydwu przypadkach (eZ Publish i Drupal) w stosunkowo łatwy sposób można przygotować serwis, który będzie w stanie przyjąć duże obciążenie. Oba CMS'y są zaprojektowane z myślą o takich konfiguracjach, oba potrafią się dobrze zintegrować z rozwiązaniami klastrowymi stosowanymi na zapleczu. Co jest istotne dla użytkownika, konfiguracja zaplecza (jak rozdzielamy ruch dla WWW, jak rozbijamy bazę danych) jest w obu przypadkach w dużej mierze przeroczysta i zajmują się nią specjaliści - administratorzy Kei.pl.
Pamiętaj, że w Kei.pl zawsze możesz liczyć na pełne wsparcie. Jesteśmy do dyspozycji 7 dni w tygodniu, 24 godziny na dobę, by służyć Ci pomocą. Masz pytania, dzwoń! Pamiętaj, Kei.pl to Niezawodny Partner w Sieci.