28/05/2007
webhosting - wprowadzenie
Wielu z nas prowadzi swoje blogi, wysyła e-maile, przegląda strony www. Często nie zastanawiamy się jednak jak wygląda to od środka - np. stawiamy pytanie: dlaczego strona www się otwiera? Postaram się przedstawić pojęcie hostingu widziane oczyma administratora.
1. określenie zakresu usług
a) interpreter dla www - Python, PHP, ASP, Java, inne.
b) bazy danych - MySQL, PgSQL, SQLite, Oracle, FireBird, inne.
c) poczta: SMTP, POP3, IMAP, antyspam, antywirus.
d) dodatki: cron (okresowe wykonywanie zadań), ssh (mozliwość wykonywania poleceń takich jak kopiowanie, usuwanie bezposrednio na serwerze).
e) backup.
f) monitorowanie usług, statystyki.
g) DNS.
h) polityka bezpieczeństwa: m.in. firewall, apparmor.
2. przeznaczenie platform serwerowych
a) pojedyncze maszyny kompleksowo obsługujące użytkowników - na jednej maszynie instalujemy wszystkie wymienione w pkt. 1 usługi.
b) rozdzielenie usług - odrębne klastry odpowiedzialne są za każdą z wymienionych w pkt. 1 usług.
3. panel zarządzania
a) autorski panel zarządzania
b) Plesk, cPanel, inne.
4. serwery, serwerownia, łącza
a) domowe data center - hosting na PC,
b) dzierżawiony hosting - serwery dedykowane u innego providera,
c) renomowane data center, własne serwery, wielokrotne łącza, własna pula IP.
Każdy z powyższych punktów w skrócie:
Dla punktu pierwszego postanawiam nie opisywać zagadnień związanych z ASP, Java, Oracle i FireBird - zostały wymienione dla pokazania zarysu usług.
Ad. 2.
Rozwiązanie 2a wydaje się prostrze do zrealizowania i z pewnością mniej kosztowne. Wadą tego rozwiązania jest to, że awaria serwera powoduje odcięcie od wszystkich świadczonych usług dla części użytkowników. Dochodzi do tego również zależność bezproblemowej pracy usług w stosunku do obciążenia serwera. Żeby nie być gołosłownym - apache będzie pracował bez zająknięcia przy loadzie 20, podczas gdy dla serwera MySQL load 6 to już katorga. Do tego pracujący cały czas system antyspamowy, który wraz z antywirusem skutecznie pożera zasoby sprzętowe.
Rasumując - rozwiązanie jest tanie na początku, kiedy nie ma zbyt wielu użytkowników, później zaczyna się kombinatorka.
Przykład 2b jest zdeydowanie bardziej kosztowny - na start potrzebujemy osobnych maszyn dla przynajmniej 3 podstawowych usług: www, baz danych, poczty. Pozostałe usługi (jak DNS czy monitoring) można dorzucić do którejś z w/w. Takie rozproszone rozwiązanie świetnie sprawdza się dla większej ilości obsługiwanych klientów. Dla przykładu - awaria serwera www pozbazwia usługi www (i tylko www !) niektórych użytkowników, np.: poczta działa dalej.
Ad. 3.
Pisanie własnego panelu zarządzania wymaga przynajmniej miesiąca przygotowań polegających na określeniu funkcjonalności owej aplikacji i sposobu jej działania, roku do 2 lat pisania kodu (2 programistów) oraz przynajmniej 3 miesięcy testów. Firmy posiadające własny (autorski) panel zarządania usługami mogą sobie pozwolić na dowolne jego modyfikacje w zależności od trendów i życzeń klientów oraz własnych pomysłów i charakteru usług. Takie modyfikacje są często, jeśli nie zawsze niedozwolone ze względu na obwarowania licencyjne czy niedostępność kodu źródłowego dla aplikacji komercyjnych. Stąd też, przykładowo przeprowadzając audyt bezpieczeństwa takich aplikacji nie jesteśmy w stanie załatać ewentualnej dziury - czekamy aż zrobi to dla nas dostawca oprogramowania, a czas spędzony na oczekiwaniach umilamy sobie żyjąc w nadzieji, że nikt z owej luki w niepowołany sposób nie skorzysta.
Warto zatem napisać własną aplikację.
Ad. 4.
Znów o kosztach. Na początek, przy niewielkiej liczbie userów, możemy sobie pozwolić na umieszczenie własnych usług wg. modelu 2a, mając na uwadze późniejszą rozbudowę platform i imigrację poszczególnych usług na odrębne maszyny - należy więc czynić odpowiednie przygotowania bazując na zamyśle rozproszenia usług. Pozwoli to zaoszczędzić na początku nieco gotówki, ale należy mieć na uwadze wady jakie niesie ze sobą to rozwiązanie. Zdecydowanie należy uwzględnić łącze, jakim będziemy dysponować - 10 Mbps (w górę i w dół) wydaje się być absolutnym minimum dla kilkudziesięciu klientów. Dla większej ilości (w tysiącach) użytkowników musimy zadbać o łącze ~50-100 Mbps i więcej, w zależności od potrzeb. Dobrym, aczkolwiek drogim rozwiązaniem jest możliwość korzystania z maksymalnej udostępnianej przez operatora przepustowości i rozliczanie się za wygenerowany ruch.
Kolejna część (postaram się w przyszły weekend) poświęcona szczegółom rozwiązań punktu 1a.
Comments(1)